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.
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.
0 Comments:
Post a Comment