Welcome to Orcmid's Lair, the playground for family connections, pastimes, and scholarly vocation -- the collected professional and recreational work of Dennis E. Hamilton

Recent Items
 
Microsoft, Interoperability, and Open Source
 
Reality Is the Model
 
Trust but Demonstrate
 
Chatting with a Spacecraft
 
OOXML: Excel2007 versus IS 29500? The Fun Begins
 
ODF1.2, My Movie Plot Defanged
 
ODF 1.2, Hijacked by OO.o?
 
Golden Geek: Wandering into Computing
 
Don't Call Me a Coder!
 
Internet Identity Workshop: May 12-14, 2008

Dreaming in Code: Going Native by the Bay?

One of the guilty pleasures of picking up Scott Rosenberg's Dreaming in Code is knowing that it mentions people that I have met, others I have heard of, and more that I could easily have bumped into unwittingly on San Francisco's Howard Street.  Although I had an unread hard-cover edition of the book, I was eager to have the paperback edition with its brief updating postscript and to settle in for a serious reading.  I've completed that, found an interesting author weblog, and noticed some unexpected side connections.

Now that my copy of Dreaming is edge-laced with little colored stickies carrying brief notes, arrows, and exclamation marks, my challenge is to organize what I sense in the work. 

One of the most infuriating aspects of the book is that it doesn't provide an answer.  I know that it would be strange if it did, because we can't know what would have made the Chandler project proceed more successfully, although I bet there are far too many groundless pet theories.   I found that I had to constantly give up trying to "fix" the project in irresistible Monday morning quarterback water-cooler style.  All through the course of the narrative, I would silently scream out something I saw the team miss, only to have it addressed or dismissed in a later passage.  This had me be very careful about what I think I know and also what I don't know about the reality for the Chandler team.  That's a good thing.

The other concern I have is the dismissiveness I see in Dreaming's treatment of software engineering.  I think the genuine progress in bringing discipline to software development is over-looked, with attention on mostly-old failures and misgivings over what "discipline" involves.  Evolving successful practice is discounted and I don't recall any report of successful cases at all.  I will dig deeper in a closer look.

Meanwhile, I wonder how much the author went native, partaking of the Silicon Valley apologetic around why software engineering is no good for our creative and innovative spirit and the need to survive in Internet time.  I find the contrast with the current Bay Bridge fiasco inapt, since the lessons to be found there are not about civil-engineering practice at all.  On the other hand, I think there might be some common lesson with the desire to "make history" with Chandler.

I fear Dreaming's characterization of software engineering is infected by the attitudes of those who claim software engineering is inapplicable or passé, probably never having practiced it successfully, meanwhile having to re-invent it, usually badly, never in the name of software engineering,  as an undertaking crashes into one wall and then the next and then the next beyond that.

Dreaming is valuable for the tension that it reveals in the struggles that projects can undergo, the seemingly chaotic and random progression that can happen in search of a conception to be wrestled into working, usable software.  I will continue to mine in the book for clues to the misapprehensions and skepticism that I see, perhaps reflecting my own more than the author's.

There is a certain literary carelessness that may be missing the larger point in some cases.  For example, Rosenberg's final chapter makes an interesting point about Frederick Brooks saying "the hard thing about building software is deciding what to say, not saying it [1: p.348]."  Unfortunately, Brooks is here talking about how speech recognition will provide at-best marginal gains in programming practice, assuming there is any value at all in speaking to a programming tool rather than writing it down [2: pp. 190-191].  How Brooks states his key message is this way:

"I believe the hard part of building software to be the specification, design, and testing of this conceptual construct [the abstract software entity], not the labor of representing it and testing the fidelity of the representation [2: p.182, emphasis in the original]."

Brooks wants us to move our attention from the accidentals (including whether we program by speaking or writing) and confront the essentials:

"We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems [2: p.182]."

Nonetheless, Rosenberg makes an interesting point of his own based on the decontextualized Brooks quotation.  It is in the deciding what to build, and how there must be far more consideration for the situation of the software as an instrument of human purpose and the difficulties that imposes.  I think Brooks would concur.

The other problem is how to actually deliver software so people can find it useful, if it is, and so the process can be corrected or abandoned if it is not.  This is indeed not how we would like major bridges to be built. but we should not confuse engineering principles with the differences that apply in different engineering situations.  We must be careful to separate the different subject matters and the context of their work from the common principles shared among the recognized engineering disciplines.  The details will differ, many of the principles do not.

---

[update 2008-06-03T00:27Z: The ultimate sentence cried out for repair; a pair of small typos reinforced the duty to update.]

1. Scott Rosenberg: Dreaming in Code.  Three Rivers Press (New York: 2007, 2008), ISBN 978-1-4000-8247-6 pbk.

  

2. Frederick P. Brooks, Jr.:  No Silver Bullet -- Essence and Accident.  pp. 1069-76 in Proceedings of the IFIP 10th World Computing Conference, H-J. Kugler (ed.), Elsevier (Amsterdam: 1986).

Page citations are to the reprinting in The Mythical Man-Month: Essays on Software Engineering Anniversary Edition, Addison-Wesley (Boston: 1995), ISBN 0-201-83595-9 pbk.  The 20th anniversary edition contains useful update chapters on the original analysis and on the "No Silver Bullets" thesis.

posted by orcmid at 6/02/2008 11:43:00 AM