I’ve previously compared software estimation to variations in the time required to drive to work.

Dispatching delivery trucks is my mental model for comparison to changes in project direction.  This can help others to understand the impact when changes happen too frequently.

A Random Walk

Using an example from the Bay Area, suppose I have a delivery truck stationed in San Francisco.

I call up the driver and ask him to make a delivery in Sacramento.  For reference, Google tells me it takes an hour and a half or so to drive from San Francisco to Sacramento.

Suppose that, 30 minutes into the trip, I call my driver and tell him to make the delivery to San Jose instead.  He’d likely be near San Pablo, only a third of the way to Sacramento. 

The driver dutifully turns around, and starts the one hour trip to San Jose.

After another half an hour, I call him up and instruct him to drive to Tracy.  From somewhere near San Leandro (and short of reaching San Jose) he would start the one hour drive to Tracy.

And so on.

What Did You Accomplish Today?

After a day of this, I recall my driver back to the home office and inquire

“How did it go?  How many deliveries did you make today?”

Exasperated, my driver informs me that, in spite of driving hundreds of miles, he failed to complete a single delivery.

(As a manager, I then express shock and outrage, and we proceed to have a conversation in which perhaps I learn the error of my ways.)

Thrashing

In computer science thrashing refers to situations in which the resources of a computer are largely (or wholly) consumed by forms of overhead, with the result of severely reduced productive output.

The concept can apply to other activities, including projects.  Changes in direction (whether literal or figurative), can happen too frequently with the result that productivity is impacted (and in the worst case, entirely eliminated).

Make sure the driver has a chance to drop off the package.

One of the challenges of running an online game (like Café World, on which I’ve spent most of my time) involves releasing new features on a regular, predictable cadence.

As a result, our team has devoted resources to collecting metrics on feature development and release timing.  We use that data as a feedback mechanism to adjust our scoping and scheduling guidelines.

The approach outlined below describes a process for constructing schedules with relatively high confidence.  It also gives a statistical foundation for justifying “padding” which might otherwise raise the eyebrows of skeptical managers. 

Driving to Work

To the left is a histogram of the time required to drive 18 miles to work, over many dozens of trips.  The data is not perfect, but roughly models a route that I drove frequently – a mix of highway and local roads.

Most days, the trip took about the same amount of time, around 30 minutes. 

An occasional traffic accident would hold things up, maybe requiring 45 minutes.  Sometimes bad weather would slow things down; an accident and bad weather together would be even worse – requiring perhaps an hour.

Rarely, with unusually clear traffic and cooperative traffic lights, I could race home in only 20 minutes.  But never faster.

Schedules Are Subjective

If you asked me “Steve, how long does it take you to drive to work?” I could sensibly answer

“About 25-35 minutes”

reflecting the average, and most common trip times.  And about half the time, I’d be right.

However if I had a 9am meeting with the CEO, you could be certain that I would leave at 8am or earlier, in order to have a nearly 100% chance of being there on time. 

If you wanted to pin me down to something certain, my answer would be something closer to

“An hour or less”

When the stakes are high, a schedule with 50% confidence just doesn’t cut it.

Variability In Driving

Relative to software development, driving to work is a technically non-complicated task (apologies to all you professional drivers out there).

Driving to work is easily understood, and easily repeatable.  In my example, the route is executed each time by the same person, in the same way.  Only the environmental conditions vary, yet they substantially impact the actual execution.

In spite of the many constants, we observe a remarkable 3:1 variation in performance (20 to 60 minutes). 

That is fairly surprising for this non-complicated task.

Tossing Coins

Imagine you are constructing a schedule comprised of 10 tasks which must be executed in sequence.  Each has an independent 50% chance of requiring 1 day to execute, and a 50% chance to require 2 days to execute.

Clearly the project will require 10 to 20 days to complete, but what would be a safe estimate?  Would the midpoint of 15 days be a reasonable schedule commitment?

This admittedly simplistic example can be modeled as a series of coin tosses, with a probability distribution as shown in the figures above and to the right.

Because the distribution is symmetric, there is only a 50-50 chance that the tasks will be completed in 15 or fewer days. 

Scheduling for 15 days is not a winning strategy for a high-confidence commitment.

In the figure to the above right, the same distribution is shown with the rightmost bins annotated with the likelihood that the completion time will be fewer than the indicated number of days.

We can use this information to construct a schedule with relatively high confidence.

The figure to the right shows a bounding box around 90% of the schedule possibilities. 

A schedule estimate between 17 and 18 days will be too short only 1 in 10 times.

Statistical Variation is the Norm

Even if our estimates are perfect (and they are not), environmental factors intrude.  The network or VPN can be down, source code control can be broken, or the build might not work.  A colleague may have gifted you with an unusually complicated branch merge.

These things happen all the time, yet we often pretend they do not.  Software estimation, even when done well, is a highly stochastic process.

Scoping for 90%

I encourage our teams to scope and schedule for a 90% on time rate, since the consequences of schedule misses are fairly severe.

When iterating over a large number of feature iterations of similar size and complexity, it is possible to accumulate statistical evidence to help drive this process in a compelling manner.

For tasks which are highly novel, unusually complicated, or having strong external dependencies, variances are naturally much higher and statistical categorization can remain elusive.

But it’s always worth tracking the original estimates, the actual execution, and their historical variations.

In the book, a boy sits lazily by the lake and observes a fly passing.  The fly in turn is pursued by a frog, who is in turn chased by a cat, and so on.

Each animal introduced is pursued by yet another, and a pattern emerges in the story.  For each new animal

• The animal is introduced
• All the prior animals are again enumerated

In this manner, following the introduction of the dog, the story goes:

The fly ran away in fear of the frog
who ran from the cat, who ran from the dog …

Cumulative Stories

This style in song form is called cumulative, and other examples include the familiar Twelve Days of Christmas, for which on day three we have

On the third day of Christmas, my true love gave to me…
3 French Hens
2 Turtle Doves
And a Partridge in a Pear Tree.

Yet another similar example is the song There Was And Old Lady Who Swallowed a Fly.  After swallowing a bird, spider and fly, the song goes

There was an old lady who swallowed a bird.
How absurd to swallow a bird.
She swallowed the bird to catch the spider,
that wiggled and wiggled and tickled inside her.
She swallowed the spider to catch the fly.
I don’t know why she swallowed the fly.
I guess she’ll die.

Each has a similar pattern.

Quadratic Behavior

With some amusement one evening while reading A Fly Went By, I realized that this style exhibits quadratic behavior.  That is, the length of the song/story increases with the square of the number of actors/stanzas. 

This is evident due to the number of actors/stanzas enumerated in each of the N segments in sequence:

1
2
3
…
N

Arranged with an equivalent number of objects (dots, for example) on each line, the sequence forms a half-triangle pattern, as pictured at the top of this article.

If you accumulate all the sizes of all the segments, we have the numerical series

1 + 2 + 3 + … + N  =  N (N+1) / 2

which, for large N, is dominated by the term N².  In computer science, an accumulation like this is frequently an indication of non-ideal algorithm design.

What’s The Bottom Line?

In summary, if you double the number of actors / stanzas, the resulting book / song will be not twice, but four times as long.  “24 days of Christmas” would be an excruciating 4 times as tedious to listen to, relative to the (already tedious) 12 days.

It isn’t very surprising, then, that these songs and books generally tend to call it quits after 8-12 segments.

In the future, my interview questions may include children’s books.

After a bit of a delay, I’ve got another book to recommend.

Joel Spolsky has kept a popular blog in the past decade, archived on his web site and in several books including Joel On Software.

Joel borrows ideas from sources like Peopleware and Mythical Man Month, as well as his experiences developing software for several companies including his own.  He’s a thought-provoking and entertaining writer, making him an easy and worthwhile read.

A Few Sections

I have a few sections to recommend, if you’re short on time

• Guerilla Interviewing
• Painless Functional Specifications
• Painless Software Schedules
• Get Crash Reports From Users – Automatically!
• Human Task Switches Considered Harmful
• Getting Things Done When You’re Only A Grunt

But the book is sprinkled with gems.

Summary

A few caveats.  I don’t always agree with Joel, but generally find his writing worth reading.  As with the other books I’ve mentioned, there is some dated material (ten years later, dot com references are sounding somewhat quaint to me).  Last, there’s quite a bit of material focused on Microsoft technologies – a reflection of Joel’s background.

Highly recommended.

The Mythical Man Month is a classic book which has profoundly affected thinking about software development processes.  Written by Fred Brooks, it is based on his management of the IBM System 360 series of computers.  This was a large software project (hundreds of developers), and some of his observations are most applicable to projects which are large, or of long duration.

The Mythical Month

The mythical man month is one of the key concepts in the book: progress on a software project will not scale linearly with the staff count, and may in some cases may have an inverse relation (adding people to a late project can cause it to fall further behind).

Brooks doesn’t simply toss this out as a hypothesis; he backs it up with analysis and examples.

Task Partitioning

Some of the ideas he introduces are gems for their concise and memorable nature.  Regarding the impact of intercommunication on the mythical man month:

Men and months are only interchangeable commodities only when a task can be partitioned among many workers with no communication between them. This is true of reaping wheat or picking cotton; it is not even approximately true of systems programming.

and this classic observation on the sequential nature of certain tasks:

When a task cannot be partitioned because of sequential constraints, the application of more effort has no effect on the schedule.  The bearing of a child takes nine months, no matter how many women are assigned.

Runny Omelets

One of my favorites is this analogy on the sense of urgency being independent of the actual time required:

Observe that for the programmer, as for the chef, the urgency of the patron may govern the scheduled completion of the task, but it cannot govern the actual completion.  An omelet, promised in two minutes, may appear to be progressing nicely.  But when it has not set in two minutes, the customer has two choices – wait or eat it raw […]

The cook has another choice; he can turn up the heat.  The result is often an omelet that nothing can save – burned in one part, raw in another.

(That is, don’t be surprised by the result if you don’t know much about cooking and impose unreasonable demands on the chef.)

Summary

Some caveats.  The book has a relative focus on observations from large software projects.  Some of the core ideas may not apply directly to your Web-2.0-rapid-prototyping-team-of-3-people.  The technological references are, of course, often dated – the book was originally published in the in mid-1970s.  The book has an academic feel to it (heavier on deep analysis than lightweight advice).

However the essentials remain relevant three decades later, and I highly recommend the book.

Peopleware is a classic book on team building, productive and “jelled” teams, individual and team productivity, and work place environment. It is thought-provoking and should be must-read material for anyone who ends up working in software development.

A few topics/chapters are particularly memorable to me

• Quality If Time Permits – knowledge workers want to produce high quality products; management and silly deadlines conspire to defeat this.
• Hiring a Juggler – you wouldn’t hire a juggler without asking him to juggle; why would you hire a programmer before asking him to code?
• Teamicide – behaviors to avoid if you want to avoid killing off your team (this chapter also introduces one of my favorites – the concept of the “quality reduced product”)

There’s a relatively strong concentration on workplace environment (offices, cubes, windows, interruptions, …), with an emphasis and data to suggest that inefficient workplaces can destroy productivity.  Workers and managers don’t always have easy ways to influence these factors, but they’re very much worth pondering.

The book gets some criticism for its focus on negative behaviors to be avoided, rather than establishing positive behaviors to emulate.  Portions of  the material are also now somewhat dated (references to intercoms and 1970s pop music come to mind). 

However criticizing this book for being dated misses the point; the fundamentals remain valid years later and this remains a classic which has influenced thinking for several decades.

Overall a great read.

Zynga executes software projects in highly compressed time frames (features in days or weeks rather than weeks or months), which presents its own unique scheduling challenges.  This has forced me to think hard about how to optimize software development while moving at what we affectionately call “Zynga Speed”.

As a result, I’ve been spending a lot of time recently pondering software schedules and project management issues.  This has brought me back to some of the books and ideas that influenced me over the years.

I’ll cover these in a little more detail in subsequent posts, but the following are three good sources that stuck with me long after I read them

• Peopleware: Productive Projects and Teams, Tom DeMarco and Timothy Lister
• The Mythical Man-Month: Essays on Software Engineering, Frederick Brooks
• Joel On Software, Joel Spolsky

While some or all of the material in each of these books may not apply to the situation you’re in, each is a thought-provoking and worthwhile read.

(Thanks for reading – Steve Klinkner)

PS To be fair, the full name of Joel’s book is

Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity