The publishing of Scott Rosenberg’s “Dreaming in Code” and the PR circle around it, has prompted Jonathan Rentzsch writing a post which criticizes one of Rosenberg’s main tenants — that ‘Programmers like to code’ — and suggests instead that ‘Programmers like problem solving’. Rentzsch goes on to claim that programmers’ urge to rewrite problematic legacy code bases is the desire to understand rather than a desire to code.
I agree with Rentzsch completely on this point, however I do believe that Rosenberg, having come from the wrong direction, has hit a point with “Rosenberg’s Law”:
“if you are doing something that has already been done — then you have a frame of reference to estimate how long it is going to take, and to guess how many people are going to be required”
I’d like to rephrase this in Rentzsch’s “problem solving” terms, and paraphrase “Rosenberg’s Law” as:
“A relationship between the unfamiliarity of a problem to the difficulty of estimating the required resources to solve it.”
Which is not surprising in hindsight, as it is a relationship between one type of uncertainty to another…
Scott Rosenberg | 05-Feb-07 at 5:58 am | Permalink
Thanks for posting about that interview with me.
The funny thing is that “programmers like to code” isn’t one of my “main tenets,” it’s a rather minor side point in a 400-page book that covers a lot of ground. The statement, in any case, is actually a quote from another writer (Larry Constantine), who said, “Unfortunately, most programmers like to program. Some of them would rather program than eat or bathe. Most of them would much rather cut code than chase documentation or search catalogs or try to figure out some other stupid programmer’s idiotic work…. Other things being equal, programmers design and build from scratch rather than recycle.”
I think Constantine and Rentzsch fundamentally disagree on this point. My own experience suggests that Constantine is right. But like all generalizations, this one is subject to plenty of challenge.
Rentzsch doesn’t seem to allow comments on his blog so I’ve been unable to respond there.
Tal Rotbart | 05-Feb-07 at 6:34 am | Permalink
Hi Scott, thanks for your comment–
I appreciate that the book (which I intend to read, promise!) must cover much more than the Constantine quote - however the interview felt somewhat focused on aspects of the ‘programmer mentality’.
I’ll take this opportunity to perhaps qualify some of my agreement with Rentzsch. I’m not sure who it was that said that a good (software) engineer is one that is ‘unlazy’ in the short term so he can be lazy in the long term. Thus while I agree with you that there’s a problem with the mentality of ‘it’s faster to write my own’, a good engineer would find the balance between reuse and rewriting.
Perhaps using something like Ruby on Rails which does plenty of magic behind the scenes to allow a coder to write small amounts of code do a lot ‘his way’, while still utilizing a large body of established, tried and true code.
The balance is easier to find with experience, and I’ve found that even with brilliant coders, the more experienced the engineer, the better they know how to strike the balance.
An important consideration is communicating expectations. Because often the coders are kept detached from the business end (management and customer expectations, business implications) and thus aren’t aware of the downside of trudging down a certain technical solution to a problem which might be beside the point by the time they are done.
Without this communication, technical types will solve the problem based on the technical merits alone, which might not be the best solution overall.
Perhaps writing their own code is the best short-term technical solution but if they had been aware of the business implications they would easily see it is not the best solution for the wider problem.