Noel: "Worse is Better." I love that. It seems to take some of the pressure off of software developers. Can you give a little overview of what the "Worse is Better" philosophy involves?

 

Kevlin: "Worse is Better" is a catchy phrase, but it is perhaps also the weakest aspect of the concept. For most people the use of the word worse gives a contradictory expectation, that by doing a bad job with the code, the architecture, the product concept or the marketing, the outcome will be better. In truth, what the philosophy embodies is a stronger emphasis on quality than is found in most approaches, but what it subverts is the expectation that some people have of what we mean by quality and how to get it.

 

Instead of aiming for full-scope perfection, take an empirical and incremental approach, ensuring that the implementation at each step is small and simple, bug-free, fast and works with existing code and software ecosystems. Reduce scope rather than compromise on quality, performance or simplicity—with a preference for simplicity of implementation over simplicity of interface if one must be traded for the other.

 

Noel: In doing some research on "Worse is Better," I found Richard P. Gabriel's website and read his fascinating piece on the evolution of the "Worse is Better" concept. I really marveled at Gabriel's own back and forth flip-flopping on whether worse actually is better. Obviously you're a supporter of the method; what are your main reasons for being behind it?

 

Kevlin: It's not the only effective way to produce things, but it is one that is often overlooked, hence my interest in it. I first encountered Richard Gabriel's writing on "Worse Is Better" in the early 1990s in the pages of JOOP, then again via my interest in patterns and his association with the patterns movement, and I was on the OOPSLA 2000 panel discussion on the topic. I feel the idea is due for a revisit. It was both prescient and provocative, but I still think it has some unexplored implications and insights to offer.

 

With "Worse Is Better" there is a sense of compromise and of embracing uncertainty and things that are real rather than ideal, hence worse, but acknowledging reality and feasibility, wrapped up in emergence and empiricism. It is therefore properly a pragmatic approach—not pragmatic in the way that most people use the word, which tends either to be a genuine euphemism for worse or a synonym for not, e.g., "pragmatic agile" is simply a way to say "not agile".

 

Noel: In looking at the components of "Worse is Better," I see where the first listed characteristic is that "the design must be simple" and then the second characteristic is "the design must be correct in all observable aspects," and then "It is slightly better to be simple than correct." How exactly does simplicity trump correctness?

 

Kevlin: I wouldn't consider the second clause as trumping correctness, but as defining a minor contextual trade-off. Looking through the definition of "Worse Is Better," you might be struck by the immense value it places on correctness, more than most other approaches that state it is a value, but don't support it beyond lip service. The "Worse Is Better" position that "the design must be correct in all observable aspects" is fairly clear on where it stands on correctness. But it is not uncompromising, as the "better to be simple than correct" compromise acknowledges.

 

When we state characteristics of a design style, such as simplicity and correctness, these characteristics are often in sympathy, but sometimes they are in tension. How do we resolve that tension? Simplicity is considered the most important characteristic. One consequence of simplicity is improved correctness: not just that it is easier to create correct code, but that it is easier to see that code is correct. As Tony Hoare observed, "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies." It is also easier to correct something that is incorrect when it is simple than when it is complicated.

 

 

Furthermore, it is easier to discard and replace something that is simple and incorrect. Because it's simple, we understand it and can replace it with confidence—than something that is complicated and incorrect — because it's complicated, we do not understand it, so replacement evokes fear. There is another side to this as well: favor something that is simple and correct over something that is complicated and correct, because, whatever our aspirations, the latter is less likely to be or to remain correct.

 

In short, the (minor) ordering of simplicity over correctness better serves the longer term than just emphasising correctness alone.

 

Noel: You mention in your abstract for your session that some of the "Worse is Better" finer points are overlooked by agile, why is this, and are the two philosophies able to be used simultaneously on the same project?

 

Kevlin: I don't see any contradiction or incompatibility, and would encourage the application of "Worse Is Better" not simply on product development that has been labelled agile, but to make product development more agile. Agile is not a defined set of practices, it is an umbrella term that covers a range of methodologies and processes, all of which are related in their ethos if not in their detail. Agile's greatest weakness is when it is perceived as a fixed set of practices, which explains why a lot of people, within, on the edges of, and outside the agile community still don't "get it".

 

"Worse Is Better" is a way of being agile, but not all of its lessons have made it into the mainstream agile canon or perception. In the best implementations of Scrum, XP, Kanban and other approaches, the incrementalism, scope management and empiricism are there, as is the emphasis on quality through refactoring, testing and feedback. But, performance, discardability, simplicity, and the relationship of the architecture to existing software ecosystems are not as central as they could or should be. This is, of course, a sweeping generalization to which we can always find exceptions. Lean Startup and Programmer Anarchy explore discardability, although typically in specific development contexts or at the expense of other qualities. But, the problem is minor at the "best implementations" end of the spectrum compared to the way that most teams pursue agility, where incrementalism is at the expense of robustness, performance, interoperability and simplicity rather than a driver for them.

 

 

Kevlin Henney is an independent consultant, speaker, writer, and trainer helping individuals, teams, and companies improve the state of their development practice. Kevlin’s development interests are in patterns, programming, and process, with a long track record in programming practices, agile skills, and software architecture. He has contributed to open source projects and been a columnist for various magazines and websites, including Better Software, The Register, Java Report, and CUJ.