A Second Look at Software Engineering a Startup
I wrote a post a while back about software engineering a startup, and Clint's comment made me realize that my post was poorly thought out and just plain bad. I argued that the quality of code you write should be related to the type of financial situation you're in. For example, if you're a funded startup, then you should be writing good, maintainable code. However, if you're not funded or if you're doing a personal project, then you should code quickly to get features out the door. I want to revise my argument.
I've now worked on two pretty large personal projects: Cellarspot and Best Seattle Bars. Cellarspot was developed in JSP, and the code we wrote was totally maintainable and robust. On the other hand, Best Seattle Bars was developed in PHP, and the code I wrote was all inline. The following analysis may be obvious, but I'll make it anyway:
Robust, Maintainable Code
Advantages: Maintainable, easily refactorable, and expandable
Disadvantages: Generally requires more work, thought, and usually a more advanced development environment
Inline Code
Advantages: Requires less work, less thought, and a much less sophisticated development enrivonment
Disadvantages: Not maintainable, not easily refactorable, and not expandable
So when should you write fast, inline code, and when should you write good, robust code? Inline code is great when you want to prototype something. It allows you to quickly launch a set of features so you can evaluate your idea. Robust, maintainable code is basically great for all other cases. Now let's examine three cases:
You write inline code and your idea blows up
Your idea takes flight and before you know it you have tons of users, tons of peers programming with you, and your users want more features and better reliability. Chances are good that you'll have to recode your entire web app, and that's going to be a HUGE upfront cost that perhaps is more costly than writing good code to begin with.
You write good, maintainable, robust code, and your idea flops
First, let me just say that I feel your pain. One might think that this case is a total waste of time, but I'll argue the contrary. I learned an insane amount by going through the process of writing good code, and it would be a good practice for me to do it again. The value one gains by going through this process is huge - it can help you get jobs (it did for me at least), and it keeps you sharp.
You use Ruby on Rails or some similar framework
Frameworks such as Ruby on Rails and Django let you write good, maintainable code very, very quickly. They let you avoid the above two cases completely, because you won't waste your time on a flopped idea and you won't find yourself scrambling for dear life if your idea blows up.
My conslusion is the following: write good, maintainable code, and choose a framework that makes it easy for you to do so. You'll avoid the upfront costs of writing good code, and you'll avoid the posiblity of large refactoring down the road.
April 24th, 2008 - 21:36
I totally agree about inline code. David Hansson (the guy who originally developed rails) recently wrote on his blog on the merits of php when it comes to rapid prototyping of really small apps.
The problem I think, as you’ve noted, is that it’s really hard to go from there to a production ready, flexible application without rewriting it.
April 24th, 2008 - 21:52
Glad you agree with me, Amit! Thanks for the comment.