A recent post by Bob Martin highlights the Start Up Trap, where a gung-ho developer forgets due care because they’re good and they’re fast. His retort: effort does not equal speed, and if you aren’t allowing for such things as refactoring and QA, you’re not going fast at all. You wouldn’t allow an accountant similar disregard of rules, would you?
If you want to go fast. If you want the best chance of making all your deadlines. If you want the best chance of success. Then I can give you no better advice than this: Follow your disciplines! Write your tests. Refactor your code. Keep things simple and clean. Do Not Rush! You hold the life-blood of your start-up in your hands. Don’t be careless with it!
Remember: The only way to go fast, is to go well.
I have to admit that in this day and age of cheap backups, I particularly have no patience for sob stories about data loss, and others have pointed on in similar poststhat any company that doesn’t have contingencies for this is similarly gung-ho. Admittedly, I may be privileged in that my previous workplace was stringent about backups—cycling Cronos drives and off-site storage—but I also have all my important work stored online.
Still, there’s also an interesting element here: that you always need to think about the wider picture of your code. Back in the day, Alan Cooper discussed how he threw away the code for his working prototype codenamed Ruby, despite it working well … and then started from scratch with what would become Visual Basic. More recently, Ben Ehkme of 42 Floors wrote similarly about prototyping in Fake it. Trash It. Build It:
We design initial prototypes that look real, talk to people about it, and try to understand what we’re going to create. And, then we trash it. Completely. Then, build it back from scratch.
These two topics may appear to be completely at odds with each other, but above all, I think they’re a reminder that sometimes you have to have the sensitivity to stop: be it to refactor your code, or just start over again with the proper build.