"Good enough" is good enough

In a EuroPython keynote (slides [PDF]), Alex Martelli, a founder of the Italian Python association and author of several Python books, shared his thoughts on software development and more generally on the path toward perfection. He observed that there's a cultural assumption that we should always be striving for perfection at all times. Martelli argued instead that "good enough" is often good enough and that this approach will, in fact, lead to better results in the long run.

Worse is Better

Martelli opened his talk by recounting a debate that was started in 1989 by Richard Gabriel. Gabriel contrasted two approaches to software design and implementation: the New Jersey style, also known as "Worse is Better", and the MIT/Stanford approach, known as "the Right Thing". These approaches can be contrasted according to four core values: simplicity, correctness, consistency, and completeness. Martelli observed that "it's hard to argue against any of these values", but that the two styles weigh the importance of the four values in different ways, which is important when there's a conflict between them.

The "Worse is Better" approach puts strong emphasis on simplicity. Simplicity pertains to both the implementation and the interface, and is a crucial consideration in the design of a system. Martelli gave Unix as an example where this approach can be observed. The question to ask, according to Martelli, is "can I think of a simple implementation of this design concept?" Correctness is obviously important, but it's more important to be simple than to be correct. In terms of consistency, the expectation is not to be overly inconsistent. Finally, completeness can be sacrificed in favor of any of the other values and it must be sacrificed if simplicity is threatened. This can be seen in the Unix philosophy "just do one thing really well", said Martelli, explaining that "well means simple". In the MIT/Stanford approach, or "the Right Thing", correctness is a top priority, as is consistency. The focus of simplicity is on the interface. The back end can be complex as long as the interface is simple. Completeness is roughly as important as simplicity.

What this means in practice is that "the Right Thing" philosophy is dominated by experts — experts who have to make the system perfect before users can access it. On the other hand, the "Worse is Better" approach makes use of incremental development. Martelli paraphrased G. K. Chesterton's quote "if a thing is worth doing, it is worth doing badly", explaining that by doing it "badly", you get there earlier — and you can work on improving it.

Martelli went on to compare Gabriel's model with Eric Raymond's The Cathedral and the Bazaar. While the former covers the software design process, the latter focuses on the development process, but there are many parallels. Martelli observed that the "Cathedral" development style is close to "the Right Thing" approach — a defining characteristic of both models is that experts are in charge. There are also many similarities between the "Bazaar" and the "Worse is Better" model: it's a chaotic, iterative process in which a crowd is in charge. Raymond's mantra "given enough eyeballs, all bugs are shallow" emphasizes that bugs are found and fixed much faster in a crowd-sourced system.

Perfect as a verb

Martelli explained the problem with "perfection", which is that releasing a "perfect" system implies BDUF — Big Design Up Front. Everything must proceed top-down: you need perfect identification of requirements, a perfect architecture, perfect design, and perfect implementation. The problem is that this approach takes forever. Martelli observed that there's always something to improve. The real world also interferes with this approach, as users or customers don't want to wait forever for a new release.

In the real world, requirements change all the time, architecture varies with design choices, design varies with implementation technologies, and the implementation always has some bugs. In fact, most bugs are only discovered in real world deployment. Martelli argued that iterative development is therefore the only viable approach: deploy something, fix bugs, and improve the system based on feedback.

Summing up his thoughts on achieving perfection, Martelli suggested that "perfect" should be understood as a verb rather than an adjective. Perfecting your software is a laudable goal, but it's a process rather than a state as you never reach perfection — the goalposts keep shifting all the time.

Bugs are a normal part of this perfection process. While many programmers believe that they write perfect code, that's not how it actually works. In 1974, Martelli, then a university student of hardware design, and two colleagues had to write a Fortran program together. They used punch cards and the program had to be perfect as they only had one chance to run it. "You know about pair programming", Martelli remarked, "this was pair punching". As it turns out, the program ran perfectly the first time. Unfortunately, this was the only perfect program he wrote in his 40 year career, so "don't count on it as your mode of development".

The main question to consider with bugs is whether they cause irrecoverable losses. As long as your software only causes problems one can recover from, you're okay, especially if the software is clearly tagged as beta. If your bug could kill someone, for example because you work on medical device control software, "a bug could easily cause irrecoverable losses" and a different approach may be required. However, this is not the case in most situations.

The other aspect to consider is whether your reputation can recover from the damage your bugs cause. Martelli explained that the key is how you respond to bug reports — a courteous, speedy response to issues is vital, even when you're not paid by the user. Users spend their time evaluating your software and reporting issues to you, so they should be respected. "The person who points out the bug is not my enemy but my best friend", Martelli noted.

In a weird way, bugs may even be seen as a feature. Martelli mentioned the service recovery paradox — there is some evidence that the customers with the highest level of satisfaction are not those who never had any problem at all, but those who successfully have had a problem resolved. While this should not encourage programmers to introduce bugs on purpose, it shows that bugs — if properly dealt with — are not the end of the world.

What not to skimp on

While Martelli encouraged a "good enough" approach to software development, he noted that there are some things you cannot skimp on. You absolutely need a lightweight, agile process. Martelli doesn't care which, but the process has to include revision control (which one doesn't matter as they are all "good enough"), code reviews, and testing. Proper release engineering practices are also crucial, so you know what was released as which version. Additionally, you must promote good coding style, clarity, and elegance. Finally, documentation cannot be skipped: "if you're not documenting what you're releasing, you're essentially asking your users to reverse engineer what you've done". Summarizing these requirements, Martelli explained that "there's no condition under which cowboy coding is acceptable".

Martelli added that security must be a concern from the start as it's very difficult or impossible to add this later. He means security in a general sense, including aspects such as privacy and auditability. On the other hand, some features that would be nice to have from the beginning can usually be added by refactoring the code later. Such features include modularity and a plug-in architecture, an API, and scalability. "You can incur some technical debt", Martelli suggested, as long as you do it with care.

Conclusion

Toward the end of the talk, Martelli gave examples from other areas of life and explained that his "good enough" philosophy is not restricted to software design and implementation. For example, he asked whether it makes senses to hire the "perfect employee". It's quite likely that such a person would not be available for hire anyway, that they would exceed the budget, or that they simply don't exist. Instead, he suggested finding a good (not perfect) candidate who is a good match, in terms of personality and company culture, and to provide training for missing skills.

Finally, Martelli clarified that his aim is not to lower expectations. You should dream big, but the best way to achieve those dreams remains the "release early, release often" paradigm and to learn from real users' interactions. The abstract of Martelli's talk noted that "this talk is probably not perfect, but I do think it's good enough" — in my opinion, and judging from the reaction of the audience, it was certainly "good enough" to provoke a lot of interesting thoughts and discussions.