The 80/20 Rule is a well-known rule of thumb within the software development community that simply states that developers spend 80% of their time debugging applications and 20% writing new code. This ratio, which would seem to some outside the software industry the very embodiment of bad productivity, is unique to the software development community. No other industry measures work performed versus the amount of error fixing that needs to take place. Can you imagine what the production numbers would be for the Big Three automakers (GM, Ford, and DaimlerChrysler) if they spent 80% of their time fixing defects instead of making new cars? They would hardly be making any cars at all, and those they did would be utterly compromised in the eyes of the consumer.

There are those who find this rule so unnerving that they dismiss it with zealous disdain. The 80/20 rule applies only to "badly organized development groups" or "unskilled amateur coders," so the argument goes; it is something that happens to "other" development shops, but not something that can happen to "our group." The reason it is commonly dismissed out of hand is that it is felt that only the most unaware and incompetent software development team could miss such a staggering sign that their group is performing so inefficiently. Yet these dissenters are in a distinct minority; the 80/20 Rule is more or less accepted within the software development industry because programmers really do spend most of their time correcting bad code rather than producing new work.

Chances are pretty good that you think the 80/20 Rule doesn't apply to you and your development group. However, as incredible as this ratio is, I would bet that there are signs somewhere within your development organization that suggest you and your fellow developers really do spend a disproportionate amount of time debugging code rather than creating new work. Is your group showing symptoms of such poor productivity? Would you even recognize these signs if you saw them? It's harder than you think to recognize them.

A small experiment will confirm this hunch. Go and talk with your fellow developers while they are working and see if they consider their work "new" or something that they are trying "to make work." Walk in at different times during the day and see what this ratio is. Better yet, do this every day for several weeks across the entire group and see what the ratio of "working on new code" to "fixing code" is. Be sure to include your own work in this mix. I think you'll find that the 80/20 Rule does apply to your group. I also think you'll find, much to your own surprise, that your fellow developers consider the time they spend fixing code - "making it work" as they say - as actual coding time. They probably don't make a clear distinction between the two activities and they certainly won't be thinking about the 80/20 Rule as a strict demarcation of their time, if they think about it at all. If this is the case - if you and your comrades don't think of fixing and coding as two separate issues - then you have a big problem on your hands.

Once this experiment is conducted, you'll have enough data to take back to your fellow programmers and to your project managers to demonstrate how the group is really spending its time. Hopefully the entire group, managers and developers alike, will recognize and appreciate this data and will be eager to change the pattern of their development time. Realistically, it is the job of your project manager to help your group do something about the ratio of time they spend on new code versus debugging. However, there are a few things that you as a developer can do to help reduce the 80/20 ratio and increase your group's productivity.

The first step you should take to remedy the effects of the 80/20 Rule on your group is to think about how you are preventing errors. Review your work environment and the tools you are using. Are your tools sufficient for the kinds of applications you are writing? Do they help improve programming conditions and reduce errors? A good code editor is mandatory - the tools integrated into WebSphere Studio are a perfect example of a comprehensive IDE that helps developers write better code by providing a robust development environment for building and testing software applications before release. If you've got the right tools, then you are on the right track for reducing the 80/20 Rule.

However, if you don't feel that you have the proper tools, or if developers pick and chose their tools by personal preference rather than by group need, then perhaps this is a good indication that there is a communication breakdown between the development group and management. This is an easily forgotten point; not all errors are generated when code is written. If developers and their managers are not communicating - if you find it difficult to get the message across that you are not equipped properly for your tasks at hand - then chances are very good that the entire group is working under a flawed process and that steps should be taken to make intra-group communication easier and more proactive to developer needs. If your development group is fairly new, or you have recently been merged into another group or organization, a lot of your 80/20 problems could stem from simple process definition issues.

The next, and more important, step you should take is to look at your own needs, and those of your fellow developers, and compare them to the needs of the entire development group. How are the needs of individual developers different - or the same - from those of the group as a whole? Where do these needs intersect? To effectively address the 80/20 disconnect, you must begin to think in terms of group needs rather than in terms of individual developer needs. For the needs of the group, you must ask if the tool that is right for the individual is also right for the entire organization. Can the IDE you like to use for your own code be used to define group behavior? This is where a comprehensive plan for error prevention can begin to take root. As a group, are you taking full advantage of such tools, using them in the correct way, not just to find and fix errors, but also to prevent errors from recurring? Is the group using a comprehensive set of coding standards? Are you using these coding standards as a filter for source-control check-in? Many of the errors that propagate in the software development life cycle come to life through inconsistencies in the way developers work on their individual projects versus their group work dynamics. It won't matter if everyone uses the same tool if they all use it in a different way; i.e., if half of your fellow developers use a standard set of coding rules and the other half uses customized rules. Errors are bound to slip through if these rule sets are at all different.

WebSphere Studio is again a good example of an IDE that allows group behavior to be predefined, monitored, and refined in an effort to eradicate errors. Parasoft has an active partnership with IBM to provide WebSphere Studio with a variety of plug-in tools that extend the capabilities of WebSphere Studio for different types of application development, such as for Java applications or Web services or Web development projects. Such partnerships and plug-in tools reduce the probability of errors being generated across the development group through the use of language-specific coding standards and automated unit tests that can be shared among programmers and altered or revised as needed.

Reducing, or even reversing, the 80/20 Rule cannot, and will not, happen overnight. Looking at the dynamics within your development group and knowing that you and your fellow programmers have the right tools may be the work of a moment, but integrating common error prevention practices for that tool throughout the group - and getting positive results- is a much longer and more difficult task. There is no silver bullet for solving the 80/20 dilemma. Numerous studies have shown that in order to get full reversal of the 80/20 Rule could take as many as eight years. Clearly, it takes skill and patience to organize a development group into an efficient working team and to get results for your efforts.

What is important to understand is that getting the upper hand on the 80/20 Rule is largely a matter of analyzing and changing group behavior to address error prevention rather than using simple error detection and correction. You cannot, and will not, get a handle on errors if you act on an individual basis to correct your own code and leave your fellow programmers "on their honor" to correct their own work. Group behavior must be focused on uniformly meeting common coding standards, unit/load/functional tests, and monitoring practices. Only when a development group approaches error prevention as the norm, rather than performing simple error detection and bug fixes on an as-needed basis, will the 80/20 ratio begin to fall.

This is not simple hyperbole or wishful thinking - the rule can, in my opinion, be reversed, and permanently so. There is no reason why developers shouldn't spend 80% of their time developing new code and only 20% of their time debugging that same code. Actually, I am much more optimistic than that - I see no reason why debugging shouldn't be reduced even further, to less than 10% of a developer's total time, if the right tools and practices are integrated into a development group and those tools and practices are maintained for optimal performance and usage. Finding the right tool, such as WebSphere Studio, is the first step. Using that tool uniformly across a development team or set of teams is the next logical, and most important, determination that you and your fellow developers will need to make.