Sakichi Toyoda and Tiny Thoughts

Joel on Software the other day had an item on Sakichi Toyoda. After reading it, the fact that I hadn't been introduced before to Toyoda's "5 Whys" struck me. It's a process for understanding that is both simple and elegant, well suited towards many tasks. It's not deterministic per se, but for the record, determinism isn't always the hallmark of excellence.

So why hadn't I been bludgeoned over the head several times by this awesome? Why hadn't it been screamed from the software engineering rooftops? And why is it that we concentrate so much on complete and multi tiered methodologies for solving development problems but not on simple tenets? I am as guilty as any. But I wish that there were a set of simple processes that would cover most of the bases. Something in the mold of the "5 whys". Something like design patterns, but applicable towards solving problems in creating software rather than the implementation of software.

Most of the methodologies that I have seen seem to fall apart through poor implementation. Agile is often poorly implemented, just like more traditional methodologies like the Waterfall. But maybe we don't need a whole big process. Maybe we need a bunch of tiny processes that can be woven together into innumerable shapes. I see Joel working in this vein, as are the people over at 37 signals. Both books are among the best that I have read in software engineering. But while both utilize this tactic, there does not seem to be anyone creating a unified list of tiny processes, and how to move forward using them instead of more involved methodologies.

Simple means simple

Today’s recurring theme of the day is that there is a problem with most software products, and that problem is that there is too much to them. The code base is too big to manage. There are too many bugs in it. There are too many features to maintain. There are too many features to explain to users. The interface is too cluttered. I could go on. But that’s the gist of the situation.

So how can we realistically set suitable barriers on software products in order to get them to meet the needs of managers, developers, designers, and users? I’ve started to think about this and one possible answer is that there should be caps on everything.

As in, these are your engineering resources, so this is how many hand coded SLOC that you can realistically manage. Keep adding SLOC until you reach your limit.

Or as in, this is the reasonable amount of time that you can expect your users to spend using your software per day. So this is how many features you can include.

Or as in, this is the amount of "stuff" that you can keep up with, so for every new "thing" that you add, you need to remove "something else" or spin it out into a new "thing" with its own resources.

The beautiful thing about jazz lies in the ability to improvise within a given framework. It’s resulted in quite a lot of awesome. Could self imposed constraints of software products do the same?

Background Reading: Size Is The Enemy