Do it Right, or Do it Now?
We recently had a development server die (fried motherboard). This, in itself, is no great surprise. This was the first server we bought when we started this company two years ago, and you expect stuff to fail from time to time. The surprise was how long it has taken us to pick up all the pieces.
There wasn't anything mission-critical running on the server--after all, it is supposed to be a development server, not a production server. Development servers get the living tar beat out of them, and every now and then they need to have stuff wiped away when someone's early development code runs amok.
But we discovered that we depend on this servers in ways we probably shouldn't. For example, we have a prototyping tool which is used by our clients to preview upcoming projects. It makes perfect sense for the prototyping tool to use the development database, rather than the production database--there's no point in going through lots of extra work to protect and store old prototypes.
When the development server went down, though, the prototyping tool stopped working (at least until we could build another development database on a different machine). Oops.
Get It Done, or Get It Right?
In any project, there's a tension between Getting It Done, and Getting It Right. This is no surprise: we live in a world of limited time and limited budgets, and we can't let the perfect be the enemy of the good enough. How a company manages this tension determines to a large extent whether a project is successful and what the end result will look like.
My own bias is to build a quick-and-dirty prototype with the absolute minimum amount of work, play with the prototype to get a better understanding of what the finished project should look like, and then build the project for real. The prototype is analogous to an architectural model, in that it looks like the real thing, but doesn't replace it. This prototype (or perhaps a series of prototypes) essentially becomes the project definition.
Our first few customer deliverables were all essentially hand-made. This was a big pain in the butt--it took half a day to produce a report--but we were able to create the prototype for the report design in less than a couple days. Since this is our main product (that plus the expertise and infrastructure to gather the data which goes into the report), having a prototype done in a couple days was a major accomplishment.
It took close to six months of development time to get the software to generate reports in its current form (which is Done Right). For three months of that, we were building reports by hand. But, having the prototype allowed us to get something in the hands of customers months earlier, and gave us an exact design for the final report generator.
This has served us well, but it does have some risks. One of the risks is that there is a temptation to try to make the prototype serve as the final product. This temptation is unique to software, where reusing code is so easy (nobody would ever suggest taking an architectural model and using it as a real building, or taking a prototype car and selling it as a final product). For the most part, we've been able to avoid this temptation, thanks in large part to a senior developer with a strong ethic of Doing It Right.
Another, more insidious, risk is for the back-burnered project. This is when we build a prototype, then decide that the finished project is a lower priority than something else. This is a perfectly legitimate business decision, but if we start relying on the prototype for needed functionality, we suddenly have a rough piece of code, which may have bugs or hidden dependencies, running in our production environment.
The trade-off is inevitable. As a startup, we can't afford to take the time or money do to everything Right before we start selling our services. By necessity, some things will be done with duct-tape and bailing wire.
The key is making sure that the most critical stuff is done Right first.