Software is Like Building a House

  • Comments posted to this topic are about the item Software is Like Building a House

  • I guess getting up and going to work shouldn't take longer than expected. Or else the boss would consider termination of employment for being late.

  • Sorry Steve, I can't relate to how 'shovelling manure' takes longer than expected - thankfully. Or warming up the tractor, artificially inseminating a cow, or similar farming-related tasks. 🙂

  • Imagine doing the task with the wrong / outdated tools and base your estimate on that. e.g How long would it take to build the fort using only a hand saw and screw driver. (50 cuts at 5 minutes each, 200 screws at 1 minute each etc). Now build it with power tools and you have plenty of time to deal with the stuff you didn't plan for etc.

    For an ETL project you could think in terms of Sql 2000 dts and then build it with SSIS

  • I think it's because most of us are basically optimists and when we estimate something we always subconsciously think of everything going right. If we really made ourselves think of everything that could go wrong our estimates might increases several hundred percent.

    And therein lies the real problem - our managers are mostly optimists too.

    Therefore, if we give an estimate with all the potential bad stuff factored in it would be in stark contrast to the timescale they imagine (or have been given by another optimist further up the food chain - especially bad if that person happens to work in marketing) This leads on to some heavy negotiation as you try and come to some middle ground so that your manager doesn't look bad when he presents it to his boss...

    ...and you're left with the sneaking suspicion that your manager now thinks you've "lost your edge" so next time you're more lilely to be more optimistic than pessimistic.

    I think that's just one of the ironies of life - we want things to happen with no hiccups and yet they rarely do, but we still hope they will.

    DB Ghost - Build, compare and synchronize from source control = Database Change Management for SQL Server

  • One of the classic side effects of dyslexia is a poor sense of time and my other half is quite dyslexic, so much so that he's nicknamed "late" Lavelle!

    If he says he will be an hour it is invariably two real hours and even when we are into the last minute of the countdown before a dinghy race start he thinks he has enough time to travel further so we always seem to end up starting late!

    Now when he estimates a time we say "Is that real time or Sandy time??" but nothing ever takes less time than an estimate!

  • Strangely enough, it rarely takes me longer than planned to travel somewhere. Even before the era of travel planners, I always managed to estimate a good ratio between distance and average speed, allowing for traffic. When I was in the army, we worked with routing/timing tables during manouvers. Has to bring back some memories for you too, Steve 🙂 Those figures must have come from years of experience. I made it good practice to make notice of my experiences in travelling for future reference.

    In project planning, I find that it helps to make for good planning when calculating back from a deadline, hard deadlines giving better results than soft ones. It forces you to really carefully analyze all the different tasks that need to be completed for the result as well as prioritizing and sorting them. It will soon tell you how much time you have for the different stages and as such, it helps the people you're working with estimating up front if they can handle things in the amount of time given.

  • Basically, we're just rubbish at this estimating lark.

    I also find that when estimating something incorrectly but in the positive way, i.e. you think you'll end up finishing sooner, that I always manage to fill the extra time anyway. Although, that's a good thing, because the extra time and care makes for a better end result.

  • The arrival of old age; it's turned up a damn sight quicker 😛


  • Unashamedly pinched from I can't remember where...

    If Architects Had To Work Like Software Designers...

    Dear Mr. Architect:

    Please design and build me a house. I am not quite sure of what I need, so you should use your discretion. My house should have somewhere between two and forty-five bedrooms. Just make sure the plans are such that the bedrooms can be easily added or deleted. When you bring the blueprints to me, I will make the final decision of what I want. Also, bring me the cost breakdown for each configuration so that I can arbitrarily pick one.

    Keep in mind that the house I ultimately choose must cost less than the one I am currently living in. Make sure, however, that you correct all the deficiencies that exist in my current house (the floor of my kitchen vibrates when I walk across it, and the walls don't have nearly enough insulation in them).

    As you design, also keep in mind that I want to keep yearly maintenance costs as low as possible. This should mean the incorporation of extra-cost features like aluminum, vinyl, or composite siding. (If you choose not to specify aluminum, be prepared to explain your decision in detail.)

    Please take care that modern design practices and the latest materials are used in construction of the house, as I want it to be a showplace for the most up-to-date ideas and methods. Be alerted, however, that kitchen should be designed to accommodate, among other things, my 1952 Gibson refrigerator.

    To insure that you are building the correct house for our entire family, make certain that you contact each of our children, and also our in-laws. My mother-in-law will have very strong feelings about how the house should be designed, since she visits us at least once a year. Make sure that you weigh all of these options carefully and come to the right decision. I, however, retain the right to overrule any choices that you make.

    Please don't bother me with small details right now. Your job is to develop the overall plans for the house: get the big picture. At this time, for example, it is not appropriate to be choosing the color of the carpet. However, keep in mind that my wife likes blue.

    Also, do not worry at this time about acquiring the resources to build the house itself. Your first priority is to develop detailed plans and specifications. Once I approve these plans, however, I would expect the house to be under roof within 48 hours.

    While you are designing this house specifically for me, keep in mind that sooner or later I will have to sell it to someone else. It therefore should have appeal to a wide variety of potential buyers. Please make sure before you finalize the plans that there is a consensus of the population in my area that they like the features this house has. I advise you to run up and look at my neighbor's house he constructed last year. We like it a great deal. It has many features that we would also like in our new home, particularly the 75-foot swimming pool. With careful engineering, I believe that you can design this into our new house without impacting the final cost.

    Please prepare a complete set of blueprints. It is not necessary at this time to do the real design, since they will be used only for construction bids. Be advised, however, that you will be held accountable for any increase of construction costs as a result of later design changes.

    You must be thrilled to be working on as an interesting project as this! To be able to use the latest techniques and materials and to be given such freedom in your designs is something that can't happen very often. Contact me as soon as possible with your complete ideas and plans.

    PS: My wife has just told me that she disagrees with many of the instructions I've given you in this letter. As architect, it is your responsibility to resolve these differences. I have tried in the past and have been unable to accomplish this. If you can't handle this responsibility, I will have to find another architect.

    PPS: Perhaps what I need is not a house at all, but a travel trailer. Please advise me as soon as possible if this is the case..


  • ...really carefully analyze all the different tasks that need to be completed for the result as well as prioritizing and sorting them.

    Therein lies the key to estimating!

    It seems that too often we have a "gut feel" for how long a task should take, and we try to fit everything that needs to be done into that feeling. But if we first break the task down into definable pieces and then estimate each individual piece, the sum of the pieces will become a much more accurate estimate.

    I've used the following example for years when discussing estimating. You are sitting in a meeting discussing some aspect of your software. A small change is needed, and you know right where that change is required. Someone asks, "How long will that change take?". "Ten minutes" you respond.

    No, that change will take four hours.

    Here are the various tasks involved:

    1. Discuss and agree upon the change

    2. Log into your system and locate and open the program

    3. Locate the area in the program where the change needs to occur

    4. Think through the change carefully to make sure there isn't other impact. May involve a quick look at other code.

    5. Change the code

    6. Test the code

    7. Move the code into whatever change-management system you may have

    8. The code may have to go through some sort of QA process, with internal analysts and/or customers.

    9. Document the code change

    10. Move code change into production

    11. Final verification that the agreed-upon change is correctly working in production.

    You could argue the application of some of the points above. The point is, in estimating we too often gloss over all the tasks required to support the primary task (#5 above), and thereby short our estimates right out of the gate.

  • Actually Jones law is (Douglas) Hofstadter's law, which states recursively

    "It always takes longer than you expect, even when you take Hofstadter's law into account"


    -- FORTRAN manual for Xerox Computers --

  • Just about the only thing that I can estimate correctly these days is brewing a batch of beer. 4.5 hours from start to finish including cleanup, and 3 weeks later I get to enjoy it...

    As for everything else, like many of the other posters have mentioned I believe the fact that we underestimate because we're either a) too optimistic or b) don't take into account all of the things that really need completed. For me it's typically a bit of both, and it's something I'm constantly striving to better myself with.


    To help us help you read this[/url]For better help with performance problems please read this[/url]

  • Whenever I start a project around the house, my wife is quick to remind me that it may become a "Broomhead Project". That is our official designation for projects that run past the estimates.

    Like when I had to replace the wax ring of a toilet. Should have been easy but the previous owner used a hammer to bend the floor bolts over. They had been too long and the plastic cap wouldn't fit over them (and hide the bent bolts). The toilet was very close to the wall forcing me to use a mini-hacksaw to cut the bolts.

    Or when I needed to fix a faucet that started to leak. When I tried to turn off the water with the valve under the sink, the handle just twisted around and around. It was stripped. When I went out to turn off the water supply to the house, the shutoff was buried under about 4 inches of mud. Also, a trip to the store to buy another valve, canister of propane, solder, flux, and copper pipe.

    The only place that I come close to completing projects on time is at work. Now if I could figure out how to write a program to put new flooring in my kitchen, I might be on-time and under budget 🙂

  • Nice to see I'm not the only one having issues with estimates. Todd has a nice comment above and I tend to agree with it. With small changes, the overhead is large and can easily overwhelm the change itself. With large changes, it's hard to estimate in detail.

    I will say that as we've built some software at End to End Training, we tend to discuss it more before we build. Spending 2-3 hours going over features and expectations a few times results in us thinking through what we want with fewer changes down the road. It's very annoying to keep discussing it without seeing progress, but it does seem to help.

    As for manure, it can easily take longer. Depends on how much hay the horses have eaten 🙂

    No comments on my video?

Viewing 15 posts - 1 through 15 (of 45 total)

You must be logged in to reply to this topic. Login to reply