Less functionality can make a better product according to the “Worse is Better” concept described 25 years ago by Richard P. Gabriel. According to Kevlin Henney and Frank Buschmann we can learn from the worse is better concept for development and architecture with agile and lean.
At the OOP 2015 conference Kevlin and Frank will give the talk “Worse Is Better, for Better or for Worse”. In their talk they will explore a product- and architecture-centric way to think about iterative and incremental development and discuss how quality and scope management can help to create successful software. InfoQ will be covering the OOP 2015 conference with write-ups, Q&As and articles.
InfoQ did an interview with Kevlin and Frank about the worse is better concept and how to use it in software design, differences between the "Good Enough Software" vs “Worse is Better” approaches, and how worse is better can be applied with agile and lean software development.
InfoQ: Can you explain the idea behind the concept of "Worse is Better"?
Kevlin: Worse Is Better was first coined and described by Richard Gabriel 25 years ago. The name is a little misleading, since it does not propose that software should be worse in the sense many people consider software to be good or bad — namely, defect rate, performance and craftsmanship — but worse in the sense of having reduced scope from a more ambitious vision of what a software product should cover. A worse is better product is developed incrementally from a minimal feature set, all the while ensuring a sound implementation and good performance.
Frank: I like the characterization given in Wikipedia: “The idea of worse is better is that quality does not necessarily increase with functionality. There is a point where less functionality ("worse") is a preferable option ("better") in terms of practicality and usability. Software that is limited, but simple to use, may be more appealing to the user and market than the reverse.”
InfoQ: What are the characteristics of a worse is better software design, can you describe them?
Frank: Start with a minimal set of useful features, and keep the software’s design simple with respect to its implementation. Ensure the software design is correct regarding all aspects of importance, that it is bug free, and runs fast. Implement the software using existing (off-the-shelf) software and with tools that its users are familiar with.
Kevlin: Start small, keep it simple, be intolerant towards bugs, make it fast, don't get lost in abstractions, take advantage of existing software and infrastructure.
InfoQ: Can you share your thoughts on the "Good Enough Software" approach. Where does it differ from "Worse is Better"?
Kevlin: The choice of words means that the Good Enough Software approach is often confused with the Worse Is Better approach, but they are almost opposite in their characteristics. The good enough in good enough software refers to intrinsic quality: defect management, code quality and performance are not prioritised or managed as critical qualities. Deadlines end up being the focus, starting with initial time to market. While such an approach can appear to pay benefits in the short term, such an approach makes little economic sense in the long run — accidental costs and delays arising from quality issues come to define the development rather than features.
Frank: Good enough software targets at time to market: the first product in a market segment that is sufficiently feature rich and stable for a broad range of users gains the biggest market share. Even if its design and implementation lacks quality and has defects, and even if better competitor products are available at a later point in time. In a nutshell, good enough software values time to market and defect management more than initial high product quality.
InfoQ: The concept of worse is better was proposed 25 years ago by Richard P. Gabriel, but we can still learn from it today. Can you explain why and give some examples of that?
Frank: We, as a software development community, still tend to over-engineer our systems. Features no one or only few users need, extreme generality, flexibility and variability in preparation of changes that are never going to happen, and so on. Result of such thinking is a design that is costly to implement, stabilize, and evolve at affordable cost and in release time-frames expected by the market, due to its high accidental complexity and technical debt. Worse is better gives us a value system for how to focus on essence – to create a minimum viable product that is simple to implement and use. If the product is successful we can incrementally evolve it from there, based on real user needs and “field experience”. That approach has been successful for a number of systems, ranging from consumer-oriented home automation systems that can be controlled via smart phone or tablet apps from anywhere, to ordering systems for retailers in areas with little or unreliable IT infrastructure. To me, the concept of apps is also somewhat following the worse is better concept. Good apps have a small but powerful feature set, are easy and intuitively to use on a familiar infrastructure, and they are fast.
Kevlin: We still see so many projects that get mired in accidental complexity, overburdened with unnecessary or poorly considered features and racking up technical debt and defects. Focusing on a simple and fast implementation rather than speculative generality and being intolerant of bugs rather than accumulating them would make a big difference to the lives of both products and developers.
InfoQ: Can you give some examples how the concept of worse is better can be applied with agile and lean software development?
Kevlin: Unless a problem is closed scope and completely defined, a development process needs to be more empirical than planned. In this sense, a product and its architecture can be treated as a combination of hypotheses, each of which needs to be understood and explored — a build block if proven, discardable if not. This fits the incremental model of Agile and Lean approaches, but with added emphasis on performance and implementation characteristics.
Frank: To me worse is better is actually a value system or set of guiding principles for developing a successful product, a kind of definition of done in terms of product features and overall design and implementation quality. Whether this product is developed in an agile or lean fashion, or with any other development process thus does not matter. One can argue that agile practices like incremental development and continuous delivery, and lean practices like elimination of waste, are in support of the worse is better concept. Yet such thinking is also adaptable to other design value systems, for example Good Enough Software. I personally find such discussion thus more theoretical than practical. Development organizations that value worse is better will find ways to realize worse is better products.
