The 80/20 Rule

Creating software is a complex business. And the bigger and more complex your project, the less likely you'll complete it on time. Repeated delays are common—even expected—in large software projects. But delays don't have to haunt your application-development project if you follow the 80/20 rule.

Vilfredo Pareto, an Italian economist, developed the 80/20 rule in the early 1900s to describe a law of income distribution: 20 percent of a nation's population holds 80 percent of the wealth. And the 80/20 rule still applies today to a surprising number of circumstances, including software development. In the software realm, the first 20 percent of the work produces 80 percent of the project, but the remaining 20 percent of the work takes 80 percent of the overall project's time. See also, "When Less Is More."

Setting overly optimistic project deadlines based on a project's early progress is an easy trap to fall into. Most projects proceed rapidly at first. This easy progress might continue through a majority of the project's development tasks. However, basing your completion deadlines on that early progress inevitably results in two things IT strives to avoid: over promising and under delivering. Although the beginning of a project goes by quickly, wrapping up projects is where the real difficulty lies, with many projects bogging down in a myriad of final details and deployment problems. When that quick progress comes to an abrupt end, the optimistic project milestones you set are the first casualties. Failing to meet deadlines erodes management's confidence in IT, which eventually creates a rift between the IT department and upper management.

However, under promising and over delivering lets you meet and exceed expectations. Your challenge comes up front in explaining your conservative time estimates for the various project tasks, which is far better than making excuses about why your team didn't finish on time. By sticking with the 80/20 rule, you can safely estimate that the final 20 percent of the project will take four times as long as the first 80 percent. The first part of a typical development cycle begins with easily verifiable goals, such as gathering requirements, designing databases, and building UIs. And modern development tools such as Visual Studio facilitate much of this work. However, the bulk of a development project lies in the underlying plumbing required to get the application ready for production. Production-quality code is different from the code you see in technical books, magazines, and Microsoft's Web documents, much of which lacks error handling and defensive-coding techniques. Error-handling code isn't pretty and takes up a lot of space, making it difficult to publish. It also tends to be application specific. Still, good error handling and defensive coding let your applications respond predictably in a variety of unpredictable situations, including those resulting from end-user error and unexpected data conditions.

When you combine this plumbing with other staid development tasks, such as testing and deployment, you can see why that last 20 percent of the project takes so much time. Failing to allow adequate time for this final, problematic 20 percent of the project is the primary cause of our epidemic of poor-quality software. But the cure is at hand. Build enough time into your project cycle to address the last 20 percent of the project. You'll reap higher-quality code, a better end-user experience, and reduced support requirements.