The Brave New World, Briefly Revisited

The Toyota Production System (TPS) was the progenitor for a variety of change-oriented manufacturing techniques. Six-sigma, Lean, and other such constructs trace their heritage to TPS. Because Agile methodologies were influenced by “lean” thinking and an abhorrence of “Big M” processes, they too have eastern roots. For me, the allure of Agile methods, regardless of flavor, has always been the recognition of software as a human act: Programmers are not automata on an assembly-line tacking trunk lids to mechanical foetuses. Incidentally, the Japanese reached the same conclusion decades ago, as described by Teruyuki Minoura, a Toyota executive:

“An environment where people have to think brings with it wisdom, and this wisdom brings with it kaizen (continuous improvement),” notes Minoura. “If asked to produce only one unit at a time, to produce according to the flow, a typical line worker is likely to be flummoxed. It’s a basic characteristic of human beings that they develop wisdom from being put under pressure. Perhaps the greatest strength of the Toyota Production System is the way it develops people.”

There can be no successful monozukuri (making thing) without hito-zukuri (making people). To keep coming up with revolutionary new production techniques, we need to develop unique ideas and knowledge by thinking about problems in terms of genchi genbutsu. This means it’s necessary to think about how we can develop people who can come up with these ideas. As our operations become increasingly global, there’s also a need to think how to implant the Toyota DNA in our overseas personnel.”

Toyota Production Control System House Diagram

This is why software development at large, legacy corporations can be so stultifying. In his prescient IEEE Computer article, Barry Boehm labels the “That’s How We’ve Always Done It” (THWADI) attitude as a paralyzing disability in the rapidly changing software world:

“There will be a lot of tensions between people and organizations rapidly adapting to change and those who prefer not to. A good example nowadays is the interaction between software developers trying to be adaptive to change within fixed-price, build-to-specification software contract structures determined by administrators practicing THWADI (That’s How We’ve Always Done It).

Of course, some THWADI is good. We will need to separate obsolete practices from enduring principles that need to be conserved.

Some other implications for software engineers’ careers are that learning how to learn will be more important than learning things…”

Software teams that grasp this reality and its implications “look” and “feel” different from the moribund organizations that churn out the same old Micro-crap. The Guardian’s web team is a recent example of the former that comes to mind.

Knuth on Software

Much attention has been paid to Knuth’s recent interview on Informit. The Slashdot thread shows all the signs of a flame war, and the blogosphere has evidenced a vigorous response as well. The maelstrom has two focii: Knuth’s rejection of most eXtreme programming (XP) practices and his admission that he wouldn’t “be surprised at all if the whole multithreading idea turns out to be a flop.” To him, the emergence of multicore processors ”looks more or less like the hardware designers have run out of ideas, and that they’re trying to pass the blame for the future demise of Moore’s Law to the software writers by giving us machines that work faster only on a few key benchmarks!” Revisions of TAOCP will not contain parallized versions of his algorithms, nor will he devote significant research time to the subject.

These criticisms are unremarkable. Jeff Atwood, among others, labeled the multicore hype an extension of the clock-speed race in the late 90’s. 900MHz is better than 700Mhz, so four cores must be better than two. Right? So say the marketing panjandrams. Most consumers lack a rudimentary understanding of computer architecture, so marketers need a comprehensible “hook.” Core count, like clock speed, seems analogous to horsepower, torque, and other “power” metrics. Consumers need such a gimick.

The criticism of Agile is even less significant. Agile introduces practices that good programmers intuitively follow. Knuth is a good programmer, and he does not need advice.

What the masses seem to have missed was this insight into Knuth’s working habits:

My general working style is to write everything first with pencil and paper, sitting beside a big wastebasket. Then I use Emacs to enter the text into my machine, using the conventions of TeX. I use tex, dvips, and gv to see the results, which appear on my screen almost instantaneously these days. I check my math with Mathematica.

I program every algorithm that’s discussed (so that I can thoroughly understand it) using CWEB, which works splendidly with the GDB debugger. I make the illustrations with MetaPost (or, in rare cases, on a Mac with Adobe Photoshop or Illustrator). I have some homemade tools, like my own spell-checker for TeX and CWEB within Emacs. I designed my own bitmap font for use with Emacs, because I hate the way the ASCII apostrophe and the left open quote have morphed into independent symbols that no longer match each other visually. I have special Emacs modes to help me classify all the tens of thousands of papers and notes in my files, and special Emacs keyboard shortcuts that make bookwriting a little bit like playing an organ. I prefer rxvt to xterm for terminal input. Since last December, I’ve been using a file backup system called backupfs, which meets my need beautifully to archive the daily state of every file.

I currently use Ubuntu Linux, on a standalone laptop—it has no Internet connection. I occasionally carry flash memory drives between this machine and the Macs that I use for network surfing and graphics; but I trust my family jewels only to Linux.

This passage reveals the character of genius, which is realized through these disciplines:

Edward Said once wrote that the American university remains the only refuge for those interested in reflection and the refinement of the intellect. What must be considered is that personal habits–not just talent and environment–have much to do with the expansion of human knowledge.

Powered by WordPress
Entries and comments feeds. Valid XHTML and CSS.