By Richard M. Marshall
We all know that we make mistakes. We also know that we should learn from them. Yet how often do we simply observe the results and fail to learn the lesson? All too often, I'm afraid. While to err is certainly a human trait, admitting to failure isn't. This tendency unfortunately snowballs so that one small error leads to projects going wildly adrift.
This is a shame, and not just for the wasted time and effort in those projects. There are many benefits from recognizing and understanding what we do wrong and helping communicate that with the people we work with.
Software developers tend to make the most mistakes in two areas—at least that's what I've experienced. The first occurs in project planning, where hopeless optimism still rules. The second takes place when they turn a blind eye to actual or potential problems, inevitably storing up much greater trouble for later.
Let's see how you can learn to avoid these classic engineering behaviors.
Estimating Inadequately
The spec looked easy. You threw your ideas around with the team, and even did some modeling. Yet somehow it took ten times longer than you expected. That might be OK if you're working on your own and your customer is in no hurry. But if you're part of a team effort, you've probably pushed out the total deadline from dependencies through the entire project's schedule. Experienced planners don't owe their gray hair to having had an easy time of it, so they build in slack time for such eventualities. Unfortunately, even that time can be used up.
What can you do about it? The first thing is to be open and communicative. Don't hide the problem by working all hours in the hopes that you'll catch up; it won't work. You're more likely to introduce more errors and slow down the project even more. The best thing to do is 'fess up and alert the project leader or whoever owns the schedule. Forewarned is forearmed: he or she may be able to help you by allocating a buddy to work with you, or push the plans around to accommodate the unexpected delay. Whatever happens, avoid the happy trap of saying "All is well."
That's not all. You need to understand why the task turned out to be more complex than you expected. The probable cause? You didn't break the problem down into small enough chunks to form a realistic notion of how long it would take.
Last weekend I decide to trim an overgrown tree in my yard. It was the first time I'd ever done it and I mainly viewed it as an excuse for buying cool new power toys—sorry, tools—including a chainsaw. I didn't have a clear plan beyond figuring out a safe way to cut off the higher branches. Needless to say, the job took much longer than I expected. I was overwhelmed by the sheer volume of biomass that fell to the ground.
Next time I'll know that there are several distinct phases to the job. Instead of using "trim that tree" as a plan, I'll plan for aerial cutting, trimming thick branches, mulching thin branches and leaves, logging thick branches, and finally gathering twigs. I'll be able to estimate the time for each of these tasks, and each time I repeat the process my estimates will get better.
Continuously monitoring and improving your skills is an essential part of any software developer's professional development. The ability to provide reasonably accurate estimates is fundamental to working for customers and with other people. Few people are lucky enough to have an innate ability in this area: most have to learn by experience. Some projects and corporations even keep databases of estimated time versus actual time for different kinds of task. Anyone planning a new project can look up likely runtimes in this valuable resource.