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!
well, if you had emoticons, the tongue-in-cheek one would have been shown. 
i guess that wasn’t obvious. the gist was to segue to what developers do. and that the reason our estimates are lousy is the same reason, alas; we’re supposed to be competent at software. certainly meant no serious observation of Steve.
As far as his incompetence is concerned, he clearly did a poor job of estimating. As I was reading his post it was very clear to me that he was WAY off in his estimates. I’ve done enough similar projects to know that digging holes and pooring concrete will easily take six hours or more. And that’s without clearing brush and hauling tons of wood up a hill. I don’t know how he thought that he was going to frame the whole thing in a day along with putting in windows and doors.
But isn’t that the point? The more you do this stuff the better you get at estimating. Not a month goes by that some management type or newbie programmer claims that they can whip something up in a couple of weeks. I just sigh and shake my head. Let them try. I’ll be here two months from now when they give up and hand it to the pros to “do it right”.
I bet Steve wouldn’t make the same mistake again…
Often, you can’t even begin to accurately estimate how long something will take until you start doing it.
This is the case in my experience. One corollary is it is much easier to get estimates right when developing additions to a previous release that embarking on a completely new development.
A doghouse eh? I think a RABID development process would be suitable for that… (sorry, couldn’t help myself…)
As always, so very true. Even genuinely small projects (like that little helper application you wrote to make that task “quicker”) can grow hopelessly out of control if you’re not careful. The art of software development estimation just that. I rarely have much of an idea how long a project will actually take until I am some way through it, and even then, I’m sometimes wrong.
Excellent blog mate, really glad I found it.
I think there’s two aspects to this. One is the ever changing client requirements and the other is the programming part. As for the programming part, it’s all about the framework. If you have a solid framework (custom built), then you are WAY ahead. Everything about a house is built around its frame. Same thing for planes. You can make the same claim about anything large scale like transportation networks for example. This way, you can attach yet more large frameworks all the way down to a doghouse.
So I take objection to the size argument. No matter the size, you should have a framework. Most confusion seems to stem from what is a framework and what is the data used by that framework. “Should I pass this object along or is the object itself supposed to handle the interaction?” style of questions. If you’ve never asked this kind of question, then OUCH!
The reason small projects work without frameworks is because there’s very few things that interact in a N to N fashion.
Excellent summary! I love Steve’s doghouse summary and in today’s world of RAD, small problems can put a big project behind
Wow, that article was bizarre. It sounds like his kids didn’t even help at all. If my Dad had been building it then spending time with the kids and, depending on their age, teaching them some stuff about construction would have been the primary goal. Of course we kids preferred the dangerous platforms we nailed up to trees ourselves anyway. What kind of spiritless kid would want an adult approved one?
Maybe programmers SHOULD build the space shuttle? The actual software used for the shuttle is only 150,000 lines long. It’s checked, Tested, integrated, checked and tested again. It’s one of the most scrutinzed pieces of code in the history of programming and in 25 years there have only been 15 versions. As far as code goes it’s almost perfect.
http://www.fastcompany.com/magazine/06/writestuff.html
His estimates were off because he had absolutely zero experience with the subject at hand. 10-15 minutes to clear brush?!?
And he was surprised that wood and concrete is heavy?!?
Without such basic knowledge, he didn’t stand a chance.
And yes, before anyone asks, I garden and do DIY construction projects. Working on finishing the basement currently.
The examples of building a House is old news.
The really interesting part, is to consider that most houses built in world history never had any kind of architect, engineer etc…
Just the local builder.
The local builder knew how to build houses because he had served a long and painful apprenticeship. If we apply that knowledge to software engineering we come up with an interesting answer.
Most engineers employed today can not possibly be expected to build a project because they are to young. This is not as outrageous as it sounds, look around. Find out how long it takes to become a real lawyer, or surgeon.
Think about it.
If you walk into a new project, is anyone over 40 or under ?
As some one a wee bit older than many of your readers, I would like to point out that trying to get employment over 45 as a software engineer is very, very painful.
MODULAR TO THE RESCUE!.. To build a entire house is alike to build a doghouse but if the project allow to, you can build many doghouse rather a big house.
The problems is not related with the SIZE of the project but the complexity.
A complex projects can take months only to determine a single task, in fact a complex projects will required to spend time (and resources) in research, sadly this research (and RD) can be indefinite, even a seasoned programmers cannot determine a correct time for research.
For David Ginger: almost any 40 year old guy must work currently in a programmer-less job just administrative, organization and such (for this age contacts and the net are more precious rather the number of certification) OR to be a good programmers (chief in projects) with a focused specialty (to be the best in a specific matter).
Also there always the choice to form a own business. A guy that worked 10 or more years programming without leveling up can be cataloged most likely a lousy programmer or simply a digitizer/transcriber, this own business cannot be exclusively a IT matters but any you like to, from to invest money, to own a farm.
Yay First post!
It’s amazing how many people read and post back to this blog.
I enjoy it very much 
This reminds me of the identity management project I was working on back at my old job. The initial estimates of getting the OID server up and populated was about 6 months, factoring in the training for OID itself and creating the proper jobs for merging and managing the identity data (coming from a seperate database).
…and THEN the politics of what the actual “ID” should be. Since this was a campus wide implementation, slated to be “THE” ID for everybody, everybody had their 2 cents. It was decided they wanted to use the ID provided by a seperate entity that wasn’t even controlled by us. Adding this layer of complexity then exposed TONS of data integrity issues that turned everything into a nightmare. There were two seperate data sources that had to be merged, processed, and THEN fed into a final repository, which was feeding OID itself.
I believe a year to year a year and a half I quit my job there (not because of this project 8^D) and they are still working on it a year later to my knowledge.
Steve should have went down to his local home improvement store and hired some “dayworkers” for the brush clear, hole digging and lugging the stuff up the hill. Outsourcing could have kept him on schedule.
Seems the the “expert” of software project estimation gets a F for estimating his DIY project. Nice looking fort, although my kids could sack it in about 10 minutes. Where’s the defenses?
The Hack here is to realize that Steve probably bills @ $200 an hour or more.
He could have hired grunt workers for $10 and hour and saved his back and his schedule.
“The underlying lesson is the same: what works for small projects may be a total disaster on a larger scale”.
Can the reverse be true? Insights from big projects failing badly on small?
I’m a solo developer working on a small, but complicated (machine learning) application. I also happen to be domain expert.
I’ve been reading and learning a lot recently about software design, possible pitfalls etc. But all of them are described for small-medium to huge projects.
I haven’t found any discussion on potential pitfalls facing solo devs. Probably because it is qute rare.
I was wondering if there are any potential issues from trying to apply various design principles from medium/big projects to one-man jobs?
What do you think?