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.
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!
UmâŚ
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 
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:
http://softwareindustrialization.com/PreparingTheWorldForSoftwareEngineeringPart1.aspx
Hey Now Jeff,
Your right on with this post, the size of the project is very important.
Coding Horror Fan,
Catto
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.
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.
Innovatics
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
http://www.hwswworld.com/wp
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.
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?