Kevlin Henney believes that it's time to revisit the thinking behind "Worse is Better," which he does in this interview with Noel Wurst. Kevlin explains that by getting past the catchiness of the phrase, and really digging deep into its real meaning, there's a real sense of agile underneath.
Worse Is Better Revisited: An Interview with Kevlin Henney
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.