Applying the rule of thirds

As the general rule goes, for every day you expect to write production code, a day should have been spent planning and designing the work, and a day should be planned to test and refine that work (see Figure 2-1). It's the simplest thing in the world, and it's an easy way to examine any existing schedule or to start a new one from scratch. If the total amount of time isn't roughly divided into the three kinds of work, there should be well-understood reasons why the project demands an uneven distribution of effort. Imbalances in the rule of thirdssay, 20% more time dedicated to testing than implementationare fine as long as they are deliberate.

Figure 2-1. The plain-vanilla rule-of-thirds project schedule.

Consider a hypothetical web development project: if you're given six weeks to launch it, the first step should be to divide that time roughly into thirds, and, using those divisions, make calculations about when work can be completed. If this doesn't provide enough time to do the work expected at a high level, then something is fundamentally wrong. Either the schedule needs to change, or the amount of work expected to be completed needs to be reduced (or any expectations of quality need to be lowered). Trimming from the design or testing time will only increase the odds that the time spent actually writing code will be misguided or will result in code that is harder to manage and maintain. The rule of thirds is useful in that it forces the zero-sum nature of projects to surface. Adding new features requires more than just a programmer implementing them; there are unavoidable design and testing costs that someone has to pay. When schedules slip, it's because there were hidden or ignored costs that were never accounted for.

2.3.1.1 Piecemeal development (the anti-project project)

For completeness, it's worth considering the simplest case possible: there is no project. All work is done on a piecemeal basisrequests come in, they are evaluated against other work, and then they are put into the next available slot on the schedule. Some development teams, web site developers, or IT programming departments work in much this way. These organizations rarely make investments or commitments in large increments. Agile methods (discussed shortly) are often recommended to these teams as the most natural system for organizing work because these methods stress flexibility, simplicity, and expectations of change. If you work on several small assignments (not projects) at a time, you will have to extrapolate from the project-centric examples I use in this book.

However, the rule of thirds still applies to these situations. Even if each programmer is working alone on small tasks, he is probably spending about one-third of his total time figuring out what needs to be done, one-third of his time doing it, and one-third making sure it works properly. He might jump back and forth between those uses of time, but as a rough way to understand any kind of work, the rule of thirds applies well at any scale.

Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment