Software Best Practices

Voices on Software Development Best Practices
Welcome to Software Best Practices Sign in | Join | Help
in Search

10x Software Development

Numerous studies have found 10:1 differences in productivity and quality among individuals and even among teams. This blog contains Steve McConnell's thoughts about how to move toward the "10" side of that 10:1 ratio. Add to Technorati Favorites

September 2007 - Posts

  • Building a Fort: Lessons in Software Estimation

    Also Known as: How I Spent My Summer Vacation

    My big project this summer was building a fort for my kids. I'd wanted to build a clubhouse or treehouse or fort or something for the past few years, but we didn't have a good place to put it. Then while clearing some blackberries in the spring I discovered that our property extended about 20 feet further into the adjacent overgrown area than I had thought, and that was the perfect place for a fort.

    Whenever I do a physical construction project like this I try to pay attention to which attributes of the project are similar to software projects and which are different. The comparisons are made more challenging by the fact that my construction projects are recreational, whereas I'm trying to draw comparisons to commercial software projects. For the first half of the project, no good similarities jumped at out me. But as the project started to take much longer than I expected, I began to see more and more similarities between my estimates on the fort and problems people run into with software estimates.

    Original Work Plan

    Here was the work plan I had carried around in my head for a few weeks before I started the project:

    Day 1: Dig holes for footings, pour concrete for footings, haul building materials from my driveway up the hill to the fort.
    Day 2: Cut posts and beams to length. This was planned as a half day because I didn't want to put too much stress on the concrete footings until Day 3.
    Day 3: Finish beams and joists and install decking; do some of the deck railings as time permits
    Day 4: Complete the fort's framing, minus the roof
    Day 5: Frame and install the roof
    Day 6: Install door and windows; finish deck railing; install trim boards
    Part time the next couple of weeks: Finish loose ends

    I won't go through all the errors in my estimates for the whole project, but let's take a look at what I really did on Day 1.

    DAY 1

    Task 1.1 Clear brush from site (~1 hour). I'd known that I had a little brush still to clear, but I thought it would take me about 10-15 minutes. Once I started looking at where I needed to put the footings, I found that I really couldn't put them where I'd planned because I would be inside the setback for the property. So I needed to move the fort back about 5 feet, and that meant clearing a bunch of brush including scrubby trees that I hadn't planned to clear.

    1.2 Survey the site and determine placement of footings (~3 hours). I'd originally planned to build the deck with 2 beams and 2 posts per beam. After looking at some span tables, I concluded that I could *probably* get away with 2 beams with 2 posts each, but what I was building was right on the border between 2 and 3 beams and between 2 and 3 posts per beam. I decided to err on the side of caution, and that meant I needed 9 footings instead of 4. Meanwhile, I had never really adjusted my time expectations to digging 9 holes instead of 4. Siting the 9 holes also turned out to be an issue because of a big stump in the middle of my area.

    Stump

    The site overall had more of a slope than I had realized. I wanted to stake out the corners and use string to locate the position of each hole and make sure the holes were square. Due to the slope, the stakes I was using weren't tall enough on the downhill side of the site, and I spent time pounding in stakes that ended up not being tall enough, then pulling them out, hammering together makeshift taller stakes, and then pounding those in.

    I ended up spending a lot of time moving stakes and string around trying to figure out how to get 9 holes that were (a) not blocked by roots from the stump, (b) not blocked by roots from the tree in back of the fort, (c) far enough back from the property line to meet the setback requirement, (d) square relative to each other (which was hard to determine at this stage because of the slope I was building on).

    1.3 Dig post holes (~2 hours). I had to dig 9 holes, 12" in diameter, 24" deep. This actually went quicker than I expected. I used a clamshell digger and for the holes where I didn't run into any roots it was something like 5 minutes per hole. The difficult holes were the holes where I ran into roots partway down and then had to hack them out. Some of the holes had quite a few roots.

    1.4 Haul 20 80# bags of concrete up the hill (~1.5 hours). I had originally thought I could haul the concrete up the hill using a wheelbarrow, but the hill was just too steep. So I had to hand carry each 80# bag one at a time. It was also about 80 degrees and 95% relative humidity at this point, which meant I needed to rest and drink water every couple of bags. The change from 4 holes to 9 holes also increased the number of bags I had to haul from about 10 to about 20.

    Hillside

    1.5 Pour 2 Footings (1.5 hours). At this point I was pretty worn out, but I also really wanted the feeling of completion from pouring at least one of the footings. So I ended up pouring 2 of the footings and calling it a day since there was no way I was going to complete all 9 of them at that point in the day.

    End of Day 1. The picture below shows how far I got at the end of Day 1.

    End of Day 1

    What Went Wrong with My Estimate for Day 1

    • I hadn't examined my planned site well enough to know what I didn't know -- i.e., my originally planned site wouldn't work and I didn't understand how much slope there was.
    • I never revised the expectations I had created while planning a 4-footing Day 1 to more appropriate expectations for a 9-footing Day 1. That one mistake affected my site layout, concrete hauling, hole digging, and concrete pouring.
    • Brush clearing just took longer than I expected, and I hadn't included it in my estimate at all.
    • Surveying the site also just took longer than I expected, and would have even without the change from 4 holes to 9.

    DAY 2

    What I could complete on Day 2 was limited by the fact that hadn't poured all the footings on Day 1, so about all I could do on Day 2 was pour the remaining 7 footings and haul the rest of the building materials up the hill. The rest of the footing pouring went fine and took about 4 hours. Then I needed to haul the materials up from the driveway. The pile of stuff didn't look all that intimidating:

    Fort Materials

    Superficial appearances aside, however, there are 10 16' 2x8 pressure treated joists in that pile, and those suckers are heavy. There are also 3 12' 4x8 pressure treated beams in that pile, and those suckers are *really* heavy! And then there were 70 2x4s and 50 lengths of 5/4" decking, and 100 2x2 balusters for the railing, and about 15 sheets of plywood, and 2 bundles of roofing shingles, and a lot of other stuff, and all this stuff just starts to add up after awhile. It took me at least 50 trips up the hill, and that ended up taking me about 3 hours.

    At the end of Day 2 I was about where I thought I'd be at the end of Day 1 after 2 pretty long days. For the record, here's what I had done at the end of Day 2:

    End of Day 2

    What Went Wrong with the rest of My Estimate for Day 1 (i.e., the Work I Did on Day 2)

    • Hauling the building materials up the hill took longer than I planned, mostly because I'd never bothered to break down the "hauling" task and realize that it was going to take 50 trips, not 10.

    DAYS 3-6

    Days 3-6 went about like Days 1 & 2 had gone, which is to say there were lots of little tasks that turned out to be medium-sized tasks, there were little tasks that I just hadn't anticipated, and most things took longer than I had planned. By the end of Day 7 (my buffer day), I was done with the tasks I had planned for Day 3 and had a tiny start on Day 4, which is to say that I'd completed the decking, hadn't started on the railings or framing, and had one wall of the fort framed, but that was all.

    DAYS 7 AND FOLLOWING

    Since I'd used up my planned full-time days on Day 7, the rest of the fort had to be completed after work, so I had to work on it only a few hours at a time, and I couldn't work on it every day. So my calendar time overrun started stretching out faster than my effort overrun did.

    OVERALL RESULTS

    My original plan had called for about a week full time and then another couple of weeks of finishing up loose ends like painting, installing trim, and so on. I finished the fort about 6 weeks after I started it, so I was about 100% over my planned schedule, and I ended up at 2-3x my originally planned effort. Here are some pictures of how it turned out:

       

    ESTIMATION LESSONS LEARNED

    I mentioned some of the specific estimation mistakes on Days 1 & 2. As I got into the project I noticed several other issues that the estimates I'd made for my project had in common with errors in software estimates that we see with our clients:

    1. Numerous unplanned problems collectively added up. Here are a few of the problems I ran into:

    • When I opened my chainsaw case, which I hadn't used in a couple of years, I found that the oil plug hadn't been screwed in tightly, and the chainsaw was covered in oil, as was the case itself. I had to clean up the chainsaw and then dispose of the oil.
    • When I was digging the holes for the footings, I chopped my layout strings a couple times with the post hole digger. I had to spend time repairing the strings and making sure that everything was still square.
    • I dropped a little piece of my laser level down the side of one of the footing holes, between the concrete form and the dirt, after I'd poured the concrete. The piece was perched about 8" into the hole, just where I couldn't reach it. If I touched it wrong, it would drop the full 24" to the bottom of the hole where there was no way I could retrieve it. So it took me awhile to figure out how to get the piece out without risking losing it altogether.
    • My jigsaw has a little compartment/drawer to put spare blades in, and it kept coming loose and spilling blades on the ground. I looked at it several times before the sunlight finally hit the opening just right to see that there was a blade stuck under the slot where the drawer is supposed to slide in that was preventing the drawer from going in quite right. Getting that blade out took about half an hour.
    • I had trouble stabilizing the deck-railing posts by the "drawbridge" (gate). In hindsight, I should have used double joists on that side of the deck, but I didn't. I spent a lot of time staring at the these two posts, wiggling them, adding blocking to the joists below, and so on.
    • There was no adequate footing for a ladder on the backside of the fort, and there was a big tree that made putting a ladder in awkward. Tasks that took 10 minutes on the front of the fort (like nailing up a facia board under the roof) took an hour on the back.

    I think these problems are EXACTLY like the kinds of problems that show up unexpectedly on software projects -- two new tools you buy don't interface with each other like they're supposed to, and you have to figure out why. Or you install a new tool and suddenly your code doesn't compile anymore. Or you have a module that keeps producing errors because the design isn't quite right; you think you can't justify completely redesigning and rewriting it, but you end up nickling and dimeing your way to a higher cost than if you had bitten the bullet and redesigned and rewritten it.

    2. Underestimation of unfamiliar tasks. My estimates weren't too far off for a lot of the work that I'd done before. But some things, like mapping out the site for the footing holes, I assumed would be 15-30 minute task ended up taking several hours.

    3. Not decomposing big tasks into smaller subtasks. I'd planned out my project in whole days. At a birds eye view nothing seems obviously wrong with planning "frame the fort in one day." But when you break it down and say, What's involved in each of the 4 walls, and then you realize that one wall includes a door, another wall includes an angled top plate, a third wall includes an angled top plate and a window, and so on, and then you think about what's involved in each one (measuring, cutting, checking for square, recutting anything that wasn't quite right, tilting the wall up, checking again for plumb and square, attaching and then removing the temporary supports, etc.), you start thinking, can I really do a whole wall in 2 hours? If the answer's even close to "no," then you start to realize that the whole estimate for that big task is probably wrong.

    3. Using overly round time units.  Using round units like "1 day" contributes to not thinking hard enough about decomposing large tasks into smaller tasks.

    4. Substituting a target for an estimate. I had 7 days to do the project, and my estimate turned out to be 7 days. That's a little suspicious, and I should have known better than to make that particular mistake!

    5. Sweeping numerous little tasks under the estimation rug. There were lots of tasks that I knew needed to be done, but I didn't want to admit that they were going to affect my schedule, and so I tried not to think about them or I minimized their impact (I realized this later). These tasks ranged from clearing brush from the site, to painting the trim, to installing the door knob. I think this is strictly similar to software estimates in which people just don't want to acknowledge that data conversion takes time, installing new tools takes time, converging each release takes time, etc., etc.

    6. Never creating a real estimate. The fact of the matter is that I carried around a rough plan in my head for weeks, but I never actually committed a schedule to paper, and I never even considered creating a detailed estimate for the project. Of course the likelihood of making the other estimation mistakes I mentioned is higher when you don't officially create an estimate!

    7. All's Well That Ends Well. My kids love their fort, and I had a great time building it. "All's well that ends well" is one reason that companies don't improve their software practices more often than they do. If people like the software that the team produced, and the software is successful, then that reduces the incentive to try to do better next time.

    Some Differences

    There were a few differences between my fort experience and a typical commercial software project:

    • There was no way I was going to compromise quality for the sake of schedule. I couldn't build something that would be hazardous to my kids or their friends. So the schedule was going to be whatever it was going to be -- it was clearly a secondary priority. We don't see many companies in which quality trumps schedule to the degree it did on this project.
    • My schedule overrun was free. My extra time was essentially free on this project -- maybe even a bonus since I was enjoying the project. So my overrun didn't imply a cost penalty. On a software project, you'd be paying for extra staff time, and so you'd have a cost overrun along with the schedule overrun.
    • The estimation error didn't really matter, because I was going to do the project regardless of what the estimate turned out to be. If I had created a real estimate and had learned that the project was going to take 100 hours instead of 50 hours, I would still have done the project. It's much harder to justify not estimating and then flying blind for a business project, especially in the era of Sarbanes Oxley.

    What Do You Think?

    Are there other lessons I should have learned? Are these the right lessons? Are these parallels between fort building and software estimation valid at all? Let me know what you think.

  • Industry Benchmarks About Hours Worked Per Week

    One of my readers asked the following very reasonable question: 

    We are looking for industry benchmarks detailing the amount of time developers spend on a percentage basis in the following three categories:

    1) Core job activities (writing, testing, deploying code, etc.)
    2) Meetings
    3) Administrative activities (training, reporting, etc.)

    The questions are reasonable. Unfortunately, one of the lessons I've learned after looking at lots of data on questions like this is that sometimes reasonable questions don't have reasonable answers!

    In this case, what I would call "project focused hours" per month can easily vary by a factor of two between different companies based on factors like how much time is spent in meetings, how long the work days are (think government job vs. internet startup), number of holidays, number of training days, number of non-project meetings, level of support required for software already in production, etc. A common "big company" planning number is 6 hours of project-focused work per day, for the days that the employee is actually at work, but that can vary a lot across big companies and even within big companies. Based on what we see in our consulting practice, I think it's rare to average 6 hours per day of truly project-focused work in a non-startup company. The most common distraction from project-focused work we see is time spent supporting prior releases that are in production.

    The number of meetings varies a lot too and is significantly affected by company culture. When I was at Microsoft in 1990-91 I probably spent less than 5 hours a week in meetings. In contrast, I had a former Microsoft employee tell me earlier this year that on the team he was on he was booked in meetings from 10:00-4:00 5 days a week. Lots of managers at other companies have told me that they're in meetings all day every day and get most of their "real work" done during evenings and weekends, so obviously there's a big difference between Microsoft 1990 and Microsoft 2007, and among different companies.

    The amount of training, reporting, etc. varies just as much--it varies even more on a percentage basis. Best in class companies typically devote 8-12 days per year to training, whereas many companies we see allow technical staff to take 1 class per year. Many of the companies we see don't systematically support any training days per year. 

    Bottom line is that there's just too much variation among companies to make meaningful statements about "benchmark" allocations to work and overhead time categories. That doesn't mean that you won't find published sources that claim to be benchmarks, but if you do those sources are usually limited by the fact that the authors haven't had exposure to enough companies to realize that there's as much variation as there is.

    Resources

Seminars           www.Construx.com           Consulting