The construction analogy — estimation

What got me thinking about the construction analogy with software development was a recent conversation I had with a design/build contracting company. We’re in the market for a new house. We sketched our design (which we’ve worked on for quite some time) and wrote up a list of general assumptions about level of quality and some details that we wanted. We sent this out as a letter to a bunch of builders.

That sounds somewhat like your typical business requirements document, doesn’t it? It’s too detailed (specifying implementation details) while simultaneously failing to mention important points. But it’s a starting point for conversations. (Continued)

The construction analogy

I’ve always been of the opinion that software construction is not like physical construction. Or, rather, that the construction part, analogous to hammering two-by-fours together when building a house, is running the compiler. And, of course, you rarely tear a house down and rebuild it over and over, until you get it right. Therefore, software development is nothing like mechanical construction.

Except, of course, when it’s very much like mechanical construction.

Conferences and Conferring

Matt Heusser just posted a blog entry on conferences, where he makes excellent recommendations. During much of my career, I relied primarily on magazines and online communications (remember CompuServe?) to broaden my horizons. These were worthwhile, but are no match for face-to-face communications. (Continued)

Agility and context switching

A Steering manager uses the Law of Diminishing Response as a guide to successful control interventions. When you consider adding some pressure, the key variable to monitor is not people’s performance, but their responsiveness. How are they responding to the existing pressures? When they hear of a new “challenge,” do they drop their head a quarter of an inch and mumble an acceptance under their breath? Do they become annoyed and give a hundred reasons why it can’t be done? Do they show external signs of panic? These are all signs that they’ve reached the point where responsiveness has gone negative, yet they are unable to control their own response.

On the other hand, are people alert and genuinely enthusiastic, able to ask penetrating questions that need answering before accepting the extra work? Can they consciously trade off less important work for high-priority assignments? These are signs that their responsiveness is still above zero, so it’s okay to pile a little more fuel on the fire; but don’t make any assumptions about next time.

Jerry Weinberg, Quality Software Management: Systems Thinking

Last month, Dmitri Zimine posted a small rant against context switching. (Continued)

It’s all about feedback

OpAmp with FeedbackIt’s stabilizing feedback that keeps a simple amplifier working as an amplifier, rather than pegging the output at the maximum positive or negative voltage. The feedback mechanism observes the output and applies a small correction to the input to counteract overreactions. Because the feedback is swift, only a small correction is needed. In fact, if the feedback were delayed, the output would tend to swing back and forth, oscillating around the desired value.

In iterative software development, we use feedback to keep the project on task. Feedback from our unit tests lets us know if our code does what we intend. Feedback from our acceptance tests lets us know if our code does what the Customer wants. What could possibly go wrong? (Continued)

Thank you, Duc Tran

Writing my introductory post led me to think of some of the many people who have taught me important lessons. One of those people was Duc Tran, an engineer I knew when I was a technician at Rixon. He taught me a technique for using an index register to keep track of current state, instead of relying on a flock of boolean values and “if” statements. That revelation changed the path of my life, and led me to seeking simpler, yet more powerful, constructs. I was caught in a lay-off (my first of many) not many months later, and I’ve lost track of Duc Tran. I doubt that he’s aware of the influence he had.

It’s perhaps a characteristic of the human condition that we are often unaware of the good we do in the world. We must keep trying in spite of the lack of feedback.


Hello. My name is George Dinwiddie and I’m a software consultant and coach. My job is helping software development teams to become more effective, while helping them accomplish their current project.

I started out in electronics. My first job was a TV-radio repairman when I was 14. After some detours such as being an English major in college, a theatre lighting and sound technician, and an organic vegetable farmer, I came back to electronics and ended up as an Engineering technician developing modems. As it happened, this was at the time that hardware was being replaced with software, and I wrote more firmware than I designed circuits.

I’ve since moved from embedded systems to primarily working on business systems–from assembly language, through procedural C and Pascal, to object-oriented Java and currently learning Ruby. And I’ve played with a lot of things in between. Throughout it all, I’ve tried to learn the best ways of doing things. And I’ve certainly learned a lot. I’m grateful to many people who, directly or through their writings, have taught me so much. And I’m very much aware that there’s an infinite amount more to learn.

The purpose of this blog is to share some of what I’ve learned in a more informal manner than the wiki that I’ve been using. Oh, I’ll continue to use that, too, but this vehicle will allow me to publish thoughts without organizing them into a structure. It will also allow for others to leave comments in reply. I’m looking forward to that! Please do let me know what you think.