Good Enough Software Does Not Mean Bad Software

Software to be released should be just “good enough” and not perfect. You hear that a lot these days. “Good enough” from whose perspective? From the perspective of people who release software or from the perspective of the people who will use software? If it is latter, then who decides what comprises “good enough”?

The thought for this post came from one of people I follow on Twitter @enkerli. In the time I have known Alexandre, I have found him to be extremely patient [he is a teacher of repute and of some experience too]. Yesterday, he tweeted -> “enjoys draft æsthetics yet wishes more developers would release stable products. / adopte certains produits trop rapidement.” You can not but realize that he must have signed up for some web application [we will be using web application scenario in this post] expecting the best, only to be let down by an application where either things are either not there or just do not work. Personally, this happens a lot. I type out the web address of this supposedly great web application after reading a review, blog post, news article – and immediately see tonnes of HTML issues – inconsistent fonts, links not linked [with a # key that seems a favorite of development teams these days], pages that are under construction [with no dates of when you expect these to be working], server bandwidth issues [with web applications unable to handle a few thousand users], forms that won’t submit no matter what you do, pages that go haywire when error messages appear at the top and emails that confuse you further. It is almost as if the teams are not asking if it is “good enough” but even if it is “bad enough”, we can always claim that this is “good enough” for now, more is coming later.

I understand the rush of releasing now than tomorrow, why teams would want to adopt this. If you see lot of people using your application, you know the major risk “Are we building the right thing the right way” is minimized. Further, if the major feedback is on product direction [what the heck is this, abandonment rates are high, XYZ do this better], it is nice to be able to figure out these issues sooner than later. There are multiple ways of checking that [for instance focus group meetings, stakeholder meetings, exclusive previews and private beta]. Probably, like all things that mean no harm, “good enough” is being used by people in a way that suits them. Hence, it is important to understand what exactly “good enough” means. One of the good definitions of “good enough” can be found here. It is more a measure of software quality [and code] – simple, correctness, consistency and completeness. Another good definition can be found here: good enough software is the best software we can write given all the external constraints (money, time, resources, inadequate information, etc) placed on us. It’s certainly not the best software we can write before we clock out to go see our son’s ball game or the best software we can write because we don’t understand the problem space and can’t be bothered to ask. James Bach of Satisfice Inc. describes “good enough” software as making rational choices in the face of market-driven projects. The idea is that it’s okay to ship with bugs as long as you ship with the “right” bugs; that, given enough benefits, the minor problems will be overlooked. You have to be able to distinguish between important and unimportant, necessary and unnecessary. According to Pete McBreen, “The decision to ship is based on the risk of shipping a software product that will be seen as low quality. Once that risk is low enough for the organization, the software is good enough to ship. Conversely, if there are not enough valuable features in the software, even if the defect count is zero, the risk of shipping is too high and the software is not good enough.”

Now, that we saw that “good enough” is not a cosmetic 2 minute pop philosophy concept – the next argument would be “it takes time to write such a software”. Yes, it does. All software needs time to think and write. How much – depends on competence of the people. Like most things Agile, it takes maturity and courage to accept shortcomings to write software that is “good enough” – in a true sense.

Advertisement