As Lincoln Loop has evolved and grown over the last year, we’ve learned a lot not only about software development, but also about all the things that accompany it like budgeting, estimating, and scheduling. Probably the most important one is the ninety-ninety rule. It states:
The first 90% of the code accounts for the first 90% of the development time. The remaining 10% of the code accounts for the other 90% of the development time.
The lesson here is that when you think you are almost done with a project, chances are there is still a lot of work left to do. Knowing the rule is all well and good, but it doesn’t help you overcome it. The important skill is being able to adjust your thinking and planning to match the estimated amount of work to the actual amount of work. When you can do this, budgeting, estimating, and scheduling become a much simpler task. Unfortunately most people find out the hard way by either eating the extra time, delivering late, or half-assing the last portion of development.
You’ve Got A Problem if…
Late in the development cycle, there are a few tell tale signs that a project has run into the ninety-ninety rule:
- it sits at “almost done” for weeks/months on end
- it lacks documentation
- it lacks tests or has a broken test suite
- it is behind schedule, but “everything will just fall into place” in the end
- major issues and “surprises” start cropping up
- features start shrinking or getting deferred
These are all signs that the developers haven’t done their research upfront and/or are cutting corners in order to make ends meet. Once you run into these issues, they are nearly impossible to recover from. Adding developers only slows the project down1. About the only thing that works is to step back and reassess the current state of the project then start over from scratch with your budgeting and scheduling.
Fighting Back
So how do you combat the ninety-ninety rule? Entire books have been written on the subject, and while we’ve gotten pretty good at it, we’re by no means perfect. What follows is a list of techniques we’ve found helpful:
Blindly Plan for it
The first instinct is just to say, “We’re always over-budget and behind schedule, let’s just bake that into our future estimates.” This is one of the ideas behind Evidence Based Scheduling. While this is a simple solution to the problem, it doesn’t really tell you where all that extra time is going.
Experience
Experience and wisdom are great ways to combat the problem. Take your lumps for doing it wrong and you tend to develop a better sense of where your time goes and what the real time needed to complete any given project will be. The issue here is that you have to do things wrong a few times in order gain the experience to do it right.
Work Breakdown Structure
A work breakdown structure involves breaking down large jobs into smaller tasks that are easier to estimate. We are big fans of this technique for a few reasons:
- It forces you to think through the entire project up front and often uncovers problem spots before development starts.
- The tasks can easily be used to create sprint backlogs (more on this below)
Daily Status Tracking
Creating a roadmap of what and when features are expected allows you to track the overall status of the project on a day-to-day basis. Harder and riskier portions can be scheduled for earlier in the development cycle when there is still time to recover from problems. We use a burndown chart to easily identify scheduling and budget issues early on in development.
Continuous Integration
Getting into the habit of regular testing during development helps developers not only write quality code, but also prevents regression bugs as the project evolves. We regularly test a handful of metrics including a passing test suite, test coverage, and code kwalitee. If any of those start to slide, it is good to know before the week of delivery.
The Ugly Truth
While all these techniques are helpful and can prevent you from making stupid mistakes, the unfortunate truth is that it is impossible to be on time and on budget for every project. It’s easy to find stories about failed software projects going over budget by millions of dollars and overdue by many years.
Further Reading
Have any tips of your own? We’d love to hear them. Leave us a comment below.
1 Also known as The Mythical Man Month
