My plane is not flying in a straight line
Posted by robkraft on October 22, 2010
I see a lot of tension during software development between getting a feature 100% right and getting something out the door. The merits for “doing it right” should be obvious, but some developers fail to see the merits of “not 100% right, but something we can release”. This problem is analogous to flying a small plane around the world. One could argue that you should take the most direct and shortest route. However, if you choose to do so, you may find that your plane has run out of fuel before you complete your journey. To successfully navigate the globe, you must take a course that is “less than optimal” because you need to make stops at fueling stations along the way. Your plane expends extra fuel because it deviates from the straight line to get to the fueling station, and it expends more extra fuel because it must alter course after fueling to get back to the optimal path. In software development, sales of your software may be your fuel, or customer satisfaction may be your fuel. Either way, there are benefits to releasing software that still has known bugs.
This scenario, like many software development scenarios, depends greatly on context. If the software maintains a life support system and is producing errors, it may be unacceptable to ship the software. If the error is that a caption is misspelled, then it may be acceptable. In my own experience, the owner of the software ultimately makes such decisions. It is the software owner that should decide if the software should be released on the promised date with bugs, or delayed to a future date in which hopefully those bugs will be fixed. For many deadlines our software team has elected to spend our last week adding a new feature instead of fixing all the bugs in other features. This is not to say that this decision is best for your environment, but for us it was more important to get the features out and get feedback on them than to have them 100% polished. Some features we release are not adopted or clients desire significant changes to them to be satisfied. In those cases, we saved a lot of time by sending out what we had instead of spending additional weeks or months to polish to perfection a feature that would not be used.