Title: Professionalism in Programming #13

How long is a piece of string? Or for our purposes, how long does a piece of string take? It's probably about as simple a question to answer, and it makes about as much sense.

This article is about software timescale estimation. It is an important skill of the 'professional' programmer. It is also one of the mystical black arts of development, based more on hunches than science, with frequently inaccurate results.

Last time we looked at software development lifecycles. In order to plan the duration of each stage of the development process we need to have an understanding of how long each task will take. This is where and why we estimate. Essentially, estimation is part of the project planning processes - but that doesn't mean that it's entirely done by the project planners!

There are many reasons why we are asked to estimate how long it will take to complete a programming task. At the initiation of a project, for example, during the feasibility study the length of each task needs to be estimated to calculate how long the entire project will take. This indicates if the project is possible, and if it is economical. From this point on the estimates should be revisited and revised throughout the life cycle of development.

All along our software timescale estimates are just educated guesses (otherwise they wouldn't be estimates). We don't really know how long a task will take until it's been completed, when it's generally too late for the information to be useful^[1]. Whilst good estimates are reasoned and justified, bad estimates are little more than a stab in the dark. This is a standard engineering issue, requiring perceptive and flexible management. It's been an engineering issue for centuries^[2]. Managers and planners deal with the estimations for the whole project and that's exceptionally hard. We'll just attempt to look at estimating single programming jobs. Thankfully that's not exceptionally hard, just really hard.

Timing estimates are important since the bulk of the cost of software development is in the manpower. Development environments and hardware costs pale into insignificance. Don't underestimate how important this estimation skill is. To get maximal team productivity the responsibility is on each member of the team to work at their best. Estimation becomes an essential skill in this context. With accurate estimates, scheduling can take place and best use of each engineer can be made. However, if an estimate is wrong and an individual slips, say by a week, every other developer that relies on that task's completion is also set back by a week. The project slips. We'll talk more about slippage later.

We see timescale estimates, taken at different times, establishing different things. The up-front estimates determine project feasibility and tend not to drill too far down to individual programming sub-tasks. Later we see detailed sub-task estimates needed for project planning. Then the actual day-to-day timing information allows managers to allocate resource effectively and ensure timely progress. Often new tasks are discovered during development which need accounting for and slotting into the schedule.

It all seems quite dull, but it is part of the commercial reality of software development.

Because if it was easy people wouldn't be paid to do it! But there's probably a better reason than that…

I live in Cambridge, my family lives in Bristol. Software timescale estimation is akin to estimating how long it will take me to visit them. Given a strong prevailing tailwind and no traffic I can pretty much tell you how long it will take me to drive there. But if there are road works, traffic jams, my car breaks down, I leave late, or I travel at rush hour this estimate becomes a lot less reliable. We can get quite some mileage out of this is an analogy.

Foreseeing some of these problems I will commit to a likely arrival "window". I know the best case journey time. I have an idea of the worst case (I've had some nightmare trips). I can judge an expected time somewhere in the middle of the two. However, I can't really account for the unforeseen - if my car breaks down I'm stuck. Mobile phones are helpful in this situation - if I'm going to be late, I can ring ahead and let my folks know to keep the dinner heated (and preferably out of the dog).

Developing a software system does have many correlations with this - potential problems to plan for, coping with the unforeseen and dependency on third parties^[3]. This begins to show us why estimating the length of a development task is so hard. In more detail:

There are lots of variables to consider.

It is simply impossible to see the unforeseen, and this makes estimation hard. We still have to account for the things that we are genuinely able to foresee. Some of the items in the above list we can reasonably expect.

The temptation to give optimistic estimates is strong. There is pressure from above to promise short schedules, so that we can win contracts, announce market releases, maintain internal political stability, and so on. This is a sad reality of the commercial world. Pressure also comes from personal pride - engineers want to promise an optimistic timescale, they are motivated people who are proud of what they deliver and how fast they can do it. However, our timescales must be grounded in reality, not in ideals.

We need to balance this with the danger of the extreme opposite. It is easy to imagine a task taking a long time, and compensating by coming up with a very large duration estimate. The danger with over estimating is that a project will always expand to fit available time! Project management involves a large amount of risk management. Our estimates can't legislate for everything - the scheduler has to be prepared to take these estimates and work them into a suitable plan, but must still be prepared to maintain flexibility.

Given that estimating how long it takes to write some software is a difficult job, how do we approach the task? At the end of the day, it's largely about experience. That's not to say it's an old man's game, but if you don't work against a backdrop of schedules, and set yourself targets to work towards then you won't grow in the skill.

Like with so much else, practise makes perfect.

However, in the Real World we rarely have the luxury of practice projects, or a sandbox to experiment with such estimation. Somewhere along the road from junior programmer to guru you have to pick this up!

Different people will work on a particular task at different rates. This is natural, everyone has a different set of skills, level of experience, confidence, and relative number of distractions (as in older projects vying for attention, or home commitments). You need to gauge how fast you work, and have a good understanding of the task you're embarking on. Estimation is personal.

We can identify a number of dangers with estimation that we can guard against when producing an estimate:

When you make the estimate it is vital to consider every activity that will be required to deliver the software. This means including:

Looking at this we understand that much less time is spent coding than initially perceived. Above all, don't forget to include testing and documentation in an estimate. They are essential, yet so many estimates given consider coding alone. With no time given to testing and documentation code is delivered that doesn't work and can't be fixed later on because no one knows how it fits together. Remember holidays and normal interruptions (meetings, training, sickness, and so on). On average around half a day a week is holiday, probably another half a day taken up on 'interruptions'. From personal experience, on one project I made an appropriate estimation for a task, but didn't contend with being pulled off to look at other issues from older projects. The consequence of this was to push back my delivery time.

A standard estimation metric is to figure out how long you think the work will take. Double that and add a week for luck. It's surprisingly accurate! When estimating several tasks that run back-to-back, watch out since more has to be done between tasks than usually anticipated.

Don't over estimate just to cover tracks. It is better to commit to doing less stuff, but better and within the projected/allotted time than to implement loads of unnecessary functionality and slip badly.

Be prepared to justify a timescale that you give - if you can't describe how you intend to approach the problem and the internal milestones you need to look at it more. If you really can't estimate a time for a task, it shows that you don't understand it fully. Perhaps you need to break it up into smaller tasks, and provide estimates for them. Spending more time on design/specification and thinking through the sub-task list will make sure you're not a factor of ten out in an estimate.

The PERT estimation technique can be helpful. It is like my arrival 'window' calculation when driving to Bristol. You estimate three times corresponding to different likelihoods of meeting delivery dates: a best case, worst case and likely case. This ties up with scheduling procedures allowing a calculation of best/worst case project time. The bigger the gap between each estimate, the bigger the risk associated with the task. Perhaps it will need more careful management, or giving to a more experienced member of staff. There are other formal estimation techniques, for example Boehm's COCOMO, which dates from 1981. Many such models are just more formal educated guesses, based on a relatively small set of empirical results. The models are often complex and rely heavily on size analysis.

Above all else, don't assume that all will go well. Invariably, it won't.

When deadlines slip engineers work very hard and get little credit. Bad estimates foster managers' incorrect assumptions about the difficulty of a task since it isn't understood how incorrect the schedule was in the first place. When it is our place to make an estimate it is therefore essential to get it right.

With this increasing pressure to be prophets as much as programmers how do we respond? The estimation neophyte sees an impractical, if not impossible task. Given a realistic estimate here are a few key ways to keep to schedules:

If you find a task taking longer than planned, it is essential to let people know. Like phoning ahead when I'm travelling to Bristol, it is better to have this fact out in the open as soon as possible. If the possibility of overrun is foreseen different scheduling decisions can be made to minimise the impact of the overrun. As the number of tasks and people increases this becomes ever more important.

There is no rigorous method to accurately perform this kind of timescale estimation. That's why it's estimation. We should be developing our estimation techniques, and become more aware and wary of potential problems. We also need to develop the ability to work to a schedule and identify when schedules are impractical.

We can draw up a plan that allows us to manage the development schedule. It is based on estimation, but in practice all we will see is how long each job really takes compared to how long we thought. Invariably, we watch the ship date slip further and further back.

Does this mean plans are useless? Absolutely not!

What do you think? Now reply.