The danger of feature-driven design

I recently re-read Douglas Crockford’s JavaScript: The Good Parts. I have been writing more and more JavaScript lately, especially object-oriented JavaScript plugging into existing frameworks. Re-reading the book has definitely been a useful exercise — I think when I first read it approximately 6 months ago, I didn’t fully understand it. But now, I do.

I also found it very interesting to hear Crockford wax poetic about the virtue of simplicity in all forms of software design. The following passage concludes the book.

When I started thinking about this[…], I wanted to take the subset idea further, to show how to take an existing [product] and make significant improvements to it by making no changes except to exclude the low-value features.

We see a lot of feature-driven product design in which the cost of features is not properly accounted. Features can have a negative value to consumers because they make the products more difficult to understand and use. We are finding that people like products that just work. It turns out that designs that just work are much harder to produce than designs that assemble long lists of features.

Features have a specification cost, a design cost, and a development cost. There is a testing cost and a reliability cost. The more features there are, the more likely one will develop problems or will interact badly with another. In software systems, there is a storage cost, which was becoming negligible, but in mobile applications is becoming significant again. There are ascending performance costs because Moore’s Law doesn’t apply to batteries.

Features have a documentation cost. Every feature adds pages to the manual, increasing training costs. Features that offer value to a minority of users impose a cost on all users. So, in designing products[…], we want to get the core features—the good parts—right because that is where we create most of the value.

We all find the good parts in the products that we use. We value simplicity, and when simplicity isn’t offered to us, we make it ourselves. My microwave oven has tons of features, but the only ones I use are cook and the clock. And setting the clock is a struggle. We cope with the complexity of feature-driven design by finding and sticking with the good parts.

It would be nice if products[…] were designed to have only good parts.

I removed direct references to the main subject of Crockford’s discussion — namely, the JavaScript language itself. The truth is, this advice is much more valuable for the design of all software products. Perhaps one day someone will write the much needed book, Startups: The Good Parts.

3 thoughts on “The danger of feature-driven design”

There’s a great chapter in Beautiful Code where the author spends the entire chapter making an algorithm more reliable and faster by progressively making it shorter, without making it less readable. The benefits of such simplicity extends far beyond feature lists. One of my favorite quotes from the chapter was from Blaise Pascal: “If I had more time, I would’ve written you a shorter letter.”

I think that’s Chapter 3, “The Most Beautiful Code I Never Wrote”, by Jon Bentley. I wrote a reflection on Beautiful Code elsewhere on my blog. Check it out:

I don’t recommend people read Beautiful Code to try to imitate some of the code described therein. Instead, I recommend you read it as a sociological or psychological study of what makes proud and bright software engineers tick. For example, for Kernighan it is the simplicity and minimalism that is embodied in UNIX. For Matz, it is the notion that the programming language should be as syntactically flexible as our real languages are. For simonpj, it’s that complicated can be made easy, given the right abstractions. And for Jon Bentley, in one of the more thought-provoking essays in the book, beauty and elegance was only perceived as the size of his code shrank.