Mike-Ward.Net

The Good Parts

I’ve been reading (and rereading) Douglas Crockford’s, “JavaScript, The Good Parts”. The style is simple and quietly disarming. The content is excellent. If I could make it required reading at my day job, I would.

One of my pet-peeves at work is that we don’t know how to say “No” to a customer or a bad idea. I’ve found it difficult to convince others. Crockford handles the issue head on and in only 5 paragraphs.

We see a lot of feature-driven product design in which the cost of features in not properly accounted. Features 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 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 is becoming negligible, but in mobile applications is becoming more 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 and programming languages, 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 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 and programming languages were designed to have only good parts.

I almost never consciously think about design in the programs I write. At least not in the sense that others would call “design”. I mostly write what’s useful and if I have any doubts, I leave it out. That occasionally infuriates others but I pay no heed. If I’m wrong, the truth of the matter eventually prevails and I admit my error. More often than not though the “issue” just dies quietly and I’m left to work on the “good parts”.