Friday’s Wall Street Journal included a book review of Almost Human: Making Robots Think,
That work, it seems, has its frustrations, and — as the reviewer, George Anders, tells it — the difficulties sound eerily like those recounted in Dreaming in Code’s description of the things that make software hard:
Mr. Gutkind’s second big insight involves Carnegie-Mellon’s approach to project management. It’s awful. Goals aren’t defined. Interim deadlines aren’t met. Crucial subsystems turn out to be incompatible. People rely on all-nighters to get everything finished. Such bad habits invite catastrophic blunders by exhausted people whose last-minute “fixes” snarl everything else.
In the most maddening breakdown of all, the scientists devising research projects seldom communicate well with the engineers trying to build them. Even the word “target” becomes a sore spot. To scientists, it means their working hypothesis. To engineers, it means the robot’s physical destination. Unaware of this gap, supposed colleagues get mired in confusing conversations.
Gutkind’s book is now on my “must read” list. One final irony to me, coming out of Dreaming in Code, is that Carnegie Mellon is not only home to Gutkind’s roboticists; it also harbors the Software Engineering Institute, which is ground zero for the CMM, CMMI, TSP and other acronymic attempts to add a framework of engineering rigor around the maddeningly difficult enterprise of producing new software. I might be jumping the gun (not having read Gutkind’s book yet), but it sounds like those roboticists and the SEI people should have lunch some time.
Post Revisions:
There are no revisions for this post.
Have you ever read “The Soul of a New Machine” by Tracy Kidder?
I’m reading it right now. It chronicles a hardware team building a new microcomputer in the late 1970s.
Oh yeah.
See for instance this post for a little bit of the background on the lengthy intertwingling of Soul of a New Machine and Dreaming in Code …
Scott,
Just completed Dreaming in Code and it was a very interesting read. One of my colleagues who consults on software process is reading it now. I liked the thematic comparison of bridge-building and programming. It’s a common reference, and it always makes me wonder whether the challenges in any complex engineering effort are more project management than they are technical. The question I have is: how much of the work do you need to understand to coordinate the effort successfully? This is a major challenge in robotics I would imagine, as in the sciences. A project manager is caught on both sides – understand too much and you overmanage, understand too little and you don’t know what (or whom) to believe.
You profile certain projects where there were lone programmers and quick turnarounds – I think this skirts many of the issues. To manage a complex effort requires difficult trade-offs and change management – and, of course, people politics. The ability to balance task and people-orientation is very difficult to find in a single individual or even a team, but it is happening all the time in the field.
I look forward to reading your forthcoming work.