I’ve been following JBQ’s series of posts about task estimation with interest, but this is the best one.

I’ve been following JBQ’s series of posts about task estimation with interest, but this is the best one. He asserts that every day you slip in coding will probably mean an addition 2 days of slip in debugging and QA because the slip represents code that is more complex than you expected.

Originally shared by Jean-Baptiste “JBQ” Quéru

Software engineering schedule trick #5

This is part 5 of a series of about 5.

Creating schedules for software engineering is hard. Some consider it a black art. I’ve learned a few tricks that make the process a bit more precise. Here’s one such trick.

Even with the best care to build precise development and stabilization schedules and running them in large teams, things can go wrong and there can be some delays. After all, the entire process is based on estimates and probabilities, and it’s not possible to reach a perfect precision.

Still, there’s one mistake that I’ve seen people do over and over: a delay in development can’t be recovered during stabilization.

Underestimating the development schedule indicates that there were additional complexities that hadn’t been taken into account during initial planning. If the code was harder to write than expected, it’ll also be harder to debug than expected.

The notion that it’s possible to miss a development deadline but to reach a final deadline by spending less time in stabilization is a nonsensical: if the code was harder to write than expected, it’ll be harder to debug than expected. For the same reason, moving the final target date by the exact development delay makes no sense either.

At the very least, the stabilization phase will grow according to the development delay. Assuming a 1:1 ratio of development and stabilization, a development phase that takes a day longer than expected will trigger a stabilization phase that also takes a day longer than expected, and the final schedule delay will be 2 days.

Even that is optimistic. When the development schedule starts to slip, pressure adds up, shortcuts are taken, and more mistakes are made. As a result, my rule of thumb is to grow the stabilization schedule by twice as much as the usual ratio. Assuming the 1:1 standardized ratio above, missing development by 1 day will grow stabilization by 2 days, for a final schedule delay of 3 days.

Finally, if multiple cycles have been scheduled ahead of time, such delays can’t be recovered in the next cycle without simplifying the scope of that cycle as well: under evidence that one schedule was prepared overly aggressively, it would be hopelessly naïve to assume that the next schedule was prepared conservatively.

See also part 1 https://plus.google.com/112218872649456413744/posts/YZZrAbJeqdb about estimating how much of an engineer’s time can actually be scheduled.

See also part 2 https://plus.google.com/112218872649456413744/posts/hGfwXrURjZD about building schedules by breaking tasks down into small sub-tasks.

See also part 3 https://plus.google.com/112218872649456413744/posts/9oYqAoSRaR4 about scheduling the debugging phases.

See also part 3.5 https://plus.google.com/112218872649456413744/posts/XQXX63yfVin about prioritizing bugs.

See also part 4 https://plus.google.com/112218872649456413744/posts/RCWDzcojg9T about scheduling in teams.

A conclusion will close this series.

One reply on “I’ve been following JBQ’s series of posts about task estimation with interest, but this is the best one.”