I met today with a young entrepreneur, you might know his kind of company. They have a niche in a local market, a sweet business model, they are four and their business is running great, they are really good at SEO and know how to strike a partnership deal.
The site is good looking. And it does what it is supposed to do.
They built everything in-house, in PHP/MySQL and they don't really have big performance issues (500ms average response time of their scripts which they find acceptable). They know they are not supposed to do sys admin and have a hosting company that takes care of their machines.
The guy writing the code is not that bad either. He doesn't really do OOP programming nor does he really know what is the practical use of the MVC pattern. But he does separate logic from design using his own templating solution, there is not a lot inline css, and the majority of the javascript code is not inline either.
So these guys are really not in that much of trouble, I can surely say I have seen much much worse.
The code to be vs. The code that is
So what do I mean when I say their code is Liability not an Asset? It means that more or less all project code is. Before you are running a live system the "code to be" represents what you need to do in order for your business to run, and make money.
Afterwards the same code, "the code that is" mostly represents the added cost to implement new features. The more code you have, the costlier it will be to add anything new. And the real bad news is that everything you add will just pile up on top of the "code that is" making every subsequent addition even costlier. Now the negative marginal utility of the existing code is not a fixed quantity : the better structured you code is, the more unit tests you have, the more cool schema-less or loose schema databases you use, the less new code is costly. This is true of course for small changes (just change the graphic design of the site), but when it goes down to structural issues (getting your site multilingual, adding user roles, changing workflows) the difference can be tremendous.
And some times it means that the moment the company succeeds in its local niche -- and wants to go bigger, go international -- or resist the big players coming to the niche market it simply can't. Even if it can now raise the money to have enough development power, it will take too long. Becoming from an innovative first player, the late to market guys can be a real hard wake up call.
Now, these companies: brave, self-financed and successful can probably not exist by doing "stuff right" from the beginning. There is an initial investment in development quality that would probably not have been able to afford. You don't have that many professional developers running around looking for biz-dev guys with an idea, willing to work for a year and a half without salary, and being able to explain to their partner: hey let's not implement anything new this week, let's write some more tests, let's just refactor that old code (from 4 weeks ago). In order to hire an external professional team well you need to have the seed money, and not everybody has access to that.
Is doom a fatality?
But doom is not a fatality, there is a tipping point. There is a specific moment in time, when the company is already successful enough a time where there is still time to refactor, not that much code has been written. Although it took a year to write it a bunch of professionals can probably redo the whole thing in a month this time with the scalability, the internationalization, the security built-in and maybe the most important, the ability to add new stuff without breaking the old one, to tweak the system without being afraid it will make the whole thing collapse.
So if you are the business guy, how can you prepare yourself well to throwing away everything and still staying in business? What can you do to make sure you will not fail by succeeding? Here is a preflight checklist you should verify with your tech guy, before you write a single line of code. If you don't know you are going to be writing marvelous code. You should try to find out how to write as less code as possible and how to make it as disposable as possible.
Best practices for people who can't follow best practices
First three:
- You are using existing open source code that enforces as many good practices as possible such as Ruby On Rails, Django or Drupal and you know the implications of the licensing model on you business model
- Your coder is a respected open source contributor, he has a bunch of projects up on github or bitbucket and many people fork his stuff
- On some of the comments you see on these platform people tend to be respectful for the number and the quality of tests he has written and praise his documentation
At this point there is a very good chance you can stop reading this. Things will be cool. Trust the tech guy. Just really make sure you have some kind of back up for your data, and if you see the tech guy drinking too much whisky before noon, also make sure you have access to backups of the code as well as the data, maybe on a physical support only you have access to.
You should still talk to the guy and make sure:
- You are paying him enough money and he won't quit on you too soon
You could also verify together:
- You are using standards, and don't invent anything but your core value
- You respect as much as possible the spirit of the framework you use
- You have discussed together the ambitions in terms of scalability, and he is thinking about that
The big checklist (not that big)
Normally the framework you have chosen will take care of most of the following. But if you can't use one (because you tech guy is too young/too old, he is not a respected open source contributor, he doesn't like frameworks for X/Y reason, he says doesn't have time for, etc.), you still must check the following list:
- The source code of the application is on an SCM (source code management system)
- You know where the SCM is. You know it is backed up. You have learnt how to get your own copy of the code or some third party you trust has
- No development is done directly on a server
- There are at least two environments: test and production. But really, there are four environments: the local environment of the developer(s), an unstable integration machine representing the current status of the code, a testing machine -- representing the next version to be put to production -- and the production environment.
- You have a procedure in place to use the SCM to move code from development to production
- If you need to put more then just code changes to production (modify database structure, dependencies on libraries/executables) you have a procedure to make these modifications
- If you have interesting data on the server (anything that if lost might pose any kind of problem), it is backed-up
- You have a way to verify that your backups work
Talk with the tech guy if you left any of the checkboxes unchecked. Stop, there is no point in reading this post any further. Talk with the tech guy again. Make sure all are checked, that you have a way to verify this. Make sure the procedures are written.
Next verify the following:
- You know what your application is supposed to do, and you know how this can be tested
- This is written in a simple text format or nice images, but both you and the developer can understand these documents
Now go on the following checklist with your developer(s):
- The application has a single point of entry
- Design is separate from application code
- The application code does not talk directly to a database but uses some kind of abstraction
- There is a single source for text strings, with every call to static text running through a translation layer
- You have a caching infrastructure in place
- You use something else than MySQL queries for full-text search
To earn some extra points try and check the following:
- You only develop the features that you can make money out of and do the simplest thing that might possibly work
- You don't develop code you are not going to immediately use
- You understand what "Horizontal Scalability" means
- You don't have anything in the architecture that prevents that
Every time you add a feature, every single time, go through the checklist. If you could not tick a checkbox, don't develop the feature.
On the next blog post in the series I will get into some more details on each element of the checklist, to be clear on how you verify this. The last chapter will address what happens when you've already started coding, and this article has put the fear of god into you.
We've been working our a** off the past few months to get the next Drupal Conference in Paris (1et-5th september) as great and as cool as possible.