Software engineering schedule trick #3

This is part 3 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.

With enough care, it's possible to create some reasonably accurate development schedules. However, development isn't the only part of software engineering. Debugging is another aspect that also takes a significant amount of time. Because of that, debugging can't be ignored while scheduling.

The problem is that debugging can't be precidely predicted ahead of time: if it was possible to know ahead of time which bugs would be created during development, those bugs wouldn't get created in the first place.

The only way to predict is to make rough estimates, which can be tuned for a given team or product. As a rule of thumb, when planning ahead of time, a starting point is to assume that debugging will take as long as development. That's not an absolute rule, and the reality will vary between teams and between products, but it's better than nothing.

Once all development is done and the only work left is debugging, it's possible to look more precisely. At that point, my rule of thumb for a starting point is that each bug takes a half-day of work. It's important to remember my first article in this series, where engineers don't have 100% of their time available, so it's unlikely that an engineer will resolve 10 bugs a week, and the reality will be closer to 5 bugs a week.

Finally, bugs are unpredictable and uneven. If engineers are pushed to fix the easy bugs first, the only bugs that'll remain in the end will be the hard ones. To avoid situations being left with bugs that are unpredictable right when predictability is most critical, it's important to work on bugs based on criteria that'll keep them mixed. Today, my favorite approach would be to hash the bug number with a strong hash and to prioritize the bugs by sorting the hashkeys.

No matter what, though, scheduling any debugging phase is very unpredictable and imprecise. The only way to get better at it is to gather data from past development cycles and to apply those to future development cycles with the same team and/or on the same product.

See also part 1 about estimating how much of an engineer's time can actually be scheduled.

See also part 2 about building schedules by breaking tasks down into small sub-tasks.

See also part 3.5 about prioritizing bugs.

See also part 4 about scheduling in teams.

See also part 5 about schedule overruns.

See also part 6 which concludes the series.

Copyright 2012 Jean-Baptiste Queru / CC BY 3.0
Stefan Sander's profile photoJason Tokarz's profile photoArne Meyer's profile photoChad Kirst's profile photo
Zach M
Thanks +Jean-Baptiste Queru. I was looking forward to reading more since your last 2 posts in this series.
Your posts need showing to the non technical managers in most organisations. So many times during feature discussions we get the when can you deliver question. There are just soon many steps in between it's hard to explain rationally.
+Jean-Baptiste Queru The more tricks you post, the more it reminds me of +Joel Spolsky's Evidence-Based Scheduling, from 5 years ago. And in a sense, this is a Good Thing™, so please keep posting!
Add a comment...