You will be wrong. You will make mistakes. You will break things. Systems will fall over and die, with you writhing in agony trying to get that all important demo working for an important customer or investor. This all happened because you changed something last minute - perhaps you were fixing a bug, or adding an all important feature, but you got lost in your code, you changed one method which subsequently broke another method - this cascaded through the system and now nothing works at all! This should not have happened! You kick yourself. You kick yourself again. And you kick your co-founder, your employees. How did this happen?
Take a deep breath - you see the reality is that from the off, your product is going to need tweaking, it will never be perfect. Your feature set? that will be built out over time - Rome wasn't built in a day. So don't worry about getting these aspects perfect. They will eventually fall together. The one thing that will never fall together, and should genuinely consume all of your energy for the first few weeks of development is the structure of your code.
If you are building out a technical product, an app, a web site, whatever your product is, don't skimp on creating a solid, readable and maintainable code base. Failure to put best practice into place will seriously bite you in the ass at every opportunity. One of the biggest mistakes that I have seen developers make is spending too much time on the functional specification of the system, preparing database structures, flow diagrams and feature specifications that on paper, look amazing. Then they rush the development of these systems and hash together spaghetti code that looks like it was written by a 4 year old. The problem with this approach is that your database structures are going to be wrong, and your flow diagrams are going to change, and your feature set - well that will balloon (we will get to that in a later post).
At Trustev, if you were to compare the first iteration of our database to the latest iteration, or the first functional commit of our codebase to the latest, you would break out in a cold sweat just thinking of the changes that had to occur to get to where we are today. The reality is that the changes we made were simplified by the flexible, maintainable code base we put in place from day one.
All this has been possible by keeping our code simple, readable and by following a few basic principles. I am not going to go into too much detail here - as all good developers will either already know these, or will Google them later anyway - but at a high level
- Blocks of code should only have a singular purpose, keeping your code maintainable
- Naming conventions - lock them down!
- Proper use of accessors is a must
- Use tools like NHibernate for connecting to your database - you are a developer not a DBA - focus on your code
- Test, test, test. If you do not have 100% unit test coverage of your code, go home. Seriously.
- Use a continuous integration tool, like TeamCity, to manage automated building and testing of your product. If setup correctly, it will make sure that you never push out a build where all your unit tests don't pass
All good startups should spend the first few weeks defining their technology stack - if you can get this right early on, it makes changes and new features so much easier to implement. Some people will say that with a startup, the whole philosophy should be to dive right in and figure things out along the way. This is true; to a point. The reality of a startup is that the product and features you offer will change pretty much on an hourly basis - if you don't have the right structure in place to support this dynamic nature then you will end up gutting your entire system almost immediately after launch, costing your a small fortune.
There will be a lot of developers reading this blog that will disagree with me on certain (and possibly all) points, and I love that kind of feedback and open debate, so please contribute below! Five years ago I was an eager developer that made every mistake possible - but thanks to some incredible mentors (this is a big shout out to Jaroslav Urban and Jason Connery) I mended my ways.
My final word of advice when building out any piece of software is to listen and learn from those around you. Genuinely, I sucked up every bit of knowledge and experience I could from those around me - don't ever be embarrassed to ask for help or guidance. It can only make you a better developer.
Chris Kennedy is the Chief Technology Officer and co-founder at Trustev. He doesn't drink coffee, which makes everyone else at Trustev suspicious.