Steve McConnell in the Doghouse

I often trot out Steve McConnell's doghouse analogy to illustrate how small projects aren't necessarily representative of the problems you'll encounter on larger projects.

This is a companion discussion topic for the original blog entry at:

I’m sure my comment’ll be rapidly covered by the conversation, but I wanted to congratulate you about this great blog. I’ve followed it for just a month but it has positively surprised me post after post.

Thank you for sharing your creativity and knowledge, and good luck with it, the feedback and the advertisers, you’ve won it.

Greetings from Spain.

Some observations:

  • doing things never done before: yes, you’ll miss the estimate but you will be much better the 2nd time.

  • hiring day laborers: still think one should have personal experience first before doing this.

  • post hole digging: should have rented a portable motorized one; this would have save MUCH time. Point – knowing what tools are available and choosing the best one.

To all those who write code and have never built a tree house, a fence, etc., get off your asses!


Isn’t the point of building your kids a fort that you do it and don’t spend just as long planning as doing? Sure, some planning is necessary, but um… Being disappointed because you are ‘off schedule’ seems to ruin the point of taking a week off to play with a chainsaw.

That said, I can see there are some parallels between building a fort and building a large piece of software, but there are some things that are disparate, too… The biggest difference in this case, to me, is that one is a hobby and one is a profession.

A full time GC who was as good at his job as Mr. McConnell seems to be would be beside himself about over-estimating the capabilities of his crew, and scrambling to fix his time schedule so the next queued up job could be approached on-time. Ever seen that happen in a programming context? Add to that that the quality issue is completely in the builder’s hands and you have a problem that seems to be defined in a completely different space.

A hobbyist’s ethic is vastly different from a professional’s… The entire mindset is different… This changes how the problem is approached as well as what ‘solved’ is defined as.

I love the fact that this makes my missing the last project deadline not such a big deal :slight_smile:

Another entry that I’ll have to post on my cubicle in the vain hope it can enlighten my colleagues and, especially, managers. At least it covers that ugly gray fabric.

Re: Being a competent software engineer means choosing appropriate strategies for the size of the project you’re working on.

Step one – how to become a competent software engineer:

Hey Now Jeff,
Your right on with this post, the size of the project is very important.
Coding Horror Fan,

This validates my method of making estimates: come up with the best number you can, then double it.

Along the way Steve applies his considerable estimation
and project planning skills to the project

As you read my post, please keep in mind that one of the main points is that I didn’t apply my estimation skills to the project. Because it was a small project, I never created a “real” estimate. One of the main points I tried to make in the post is that IF I had applied any real estimation skills at all I could have eliminated many of the estimation errors I made. In other words, my estimation errors on the fort/doghouse project were nearly all errors of omission rather than errors of commission.

The funny thing is, I work with the folks who build the space shuttle (or write the software, anyway). You’d be surprised what it’s like here. Because of efficiency concerns, stuff like readability and expandability has to be sacrificed quite often (the computers onboard have 1MB memory and run at 40MHz)

Not really relevant, but I found your reference amusing. :slight_smile:

That’s a classic one where I work - “It’s just a small piece of work, it’s not worth doing the analysis and estimation”.

WRONG! Invariably there are things that we might have noticed if we’d taken the time to do the analysis.

I belive it’s the number of “domains” that are important, where compromises are needed to be decided. Physics? Laws?..and when the number of domains increases the connections (dependencis) between them increases exponential like when the number of communication nodes increases.


What is Innovatics? You cannot find it neither in google or any other leading search engines, nor in wikipedia or alike. Innovatics, we invent it from Innovation, just like Informatics from Information.

What is Informatics? Informatics is the study of natural and artificial systems that sense, store process and communicate information. It includes the disciplines of Artificial Intelligence, Cognitive Science, and Computer Science.

Now what is Innovatics? Innovatics is the study of how to innovate; it is the science of creation. It includes the disciplines of engineering science, management science, psychology and philosophy.

Frontier Blog - Innovatics Pionner

As my olde Pappy used to say “measure twice, cut once”. Actually he still says it when he gets the chance. It’s true no matter what the size of the project.
I think that half of the problem is that the training we receive in school is more geared towards large and very large projects. No ones going to trust one of those to a graduate fresh out of school. So we get given the small projects; attempt to apply our large project training to them; find that the overheads compared to the benefits are small and just wing it. By the time you get given a large project you’ve become cynical and resistant to large project techniques leading ultimately to failure.

what went unsaid: he got so far behind just because he didn’t know what he was doing. nothing more. he was incompetent. nothing more. now, in context, that’s not a problem. he was building he kids’ fort.

on the other hand, many people who purport to be software engineers exhibit the same behaviour. but… rather than 'fess up that they’re incompetent, they wave their hands and say that it’s not predictable. nonsense. Boeing knows, and knew, how long it would take to make a 787… until they hit their area of incompetency: how to manufacture fibre fuselages. but nobody had done that before. they didn’t have records of time/materials for tasks which, taken together, added up to a fibre fuselage. they had no idea.

the lesson: you can only estimate with accuracy that which you have done before and recorded. industrial organizations, as Boeing, have been doing this since at least Taylor (see the Wikipedia article for Time and Motion Study). software folk prefer to think that each project/task is very unique, and thus not truly estimable. we’re kidding ourselves.

he was incompetent.

I don’t know if this is a fair statement. I couldn’t have done anything he described. I don’t even own a chainsaw!

I do agree with Jon R. that hiring day laborers could have helped with the early grunt work, though-- and moving those giant sacks of concrete, and the wood from the driveway.

1 Like

Funny that when I read about a dad building a “fort” for his kids the first thing that enters my head is something crazy simple, like a fort made out of refridgerator boxes or something like that. Then upon closer look he means “fort” as in an out right club house with everything shy of running water!

Not only should you pick the proper strategy for the project, but make sure everyone knows the difference between a doghouse and penthouse.

You can get this philosophy by watching any of the “build shows” on discovery, AE, or TLC. No firm schedule ever works. On every episode of American Chopper, there’s concern for hitting the deadline, and while you may just think that they’re making it up for TV drama, it’s really true on any scheduled project. Disciples of Murhpy’s Law know that you had better plan some serious buffer time in that schedule, because something somewhere will break. That’s the interesting part about those kinds of shows. If everything were as easy as “hey, let’s go build a chopper” then I wouldn’t watch it, but I love seeing what new problems will pop up in the process, like a bent rim or a minute measuring error that screws the whole frame up.

I like Scott’s original comment. I quote here in full glory:

Someone comes to me with dried paint roughly in the shape of a doghouse, they want me to fill in the doghouse underneath, but they want me to change the color of the paint, and, to be perfectly honest, what they really want is a 5 bedroom house for their family and they figure that since the doghouse is roughly the same shape as a person-house it should be easy to just make the doghouse-paint bigger right?