As developers we are often faced with the issue of time vs. quality. Let’s face it though, we could spend forever getting it all just right, from documentation right through to unit testing. However, there has got to be a point when you let it go and see how it flies.
This is particularly true when you are faced with a real-world optimization problem, e.g. scheduling, time tabling, process optimization. Often with this type of problem it is very difficult to obtain an optimal solution. However, I find the more time you spend on the problem the better you understand it, which normally leads to an improved model. In turn, the improved model leads to a better solution, or an equivalent solution found in a shorter time.
This begs the question when do you give up and say it’s finished?
To be honest, I’m not sure what the answer is to that. As a developer I want to keep on going, hoping to pull the rabbit out the bag, but as an employer, I just want the thing done good enough to have a competitive edge.
The same goes for unit testing – especially at a startup. In this setting you are NOTHING until you get your product out the door, and until you do, you are hoping and praying that no one beats you to the punch. Some people say that quality shines through, but how bright it shines I’m not sure. Take myspace as the perfect example. It has no redeeming features – it just got there before everyone else. Does anyone know a band not on myspace though?
However, Google proved that the best product can establish its market regardless of its starting position – I now find it difficult to believe that I thought Altavista was good. It’s important to remember though that for every Google there is a myspace (or the ipod, for that fact) where the first is not the best, but people have invested too much time in their choice to change (or in the case of the ipod, maybe it’s fashion outshining functionality).
So what IS the answer to when is the software ready to go? Maybe the simple answer is “whenever someone is willing to buy it”!