Want to quickly know how good a project manager is? Here is an old consultant’s trick: Ask a programmer on the team how much throwaway code he or she used during the last project. A good 80/20 rule is the more throwaway code used during development, the better the project manager.

Throwaway code refers to the temporary software programs and routines created to help in the coding, testing, conversion, and implementation of the final (deliverable) system. There is almost universal use of throwaway code in creating conversion software, the programs used to move data from the old filing system to the new one.

After the conversion is successfully completed, the conversion software is often discarded, leading to the label, throwaway.

Although conversion software might be the most obvious use of throwaway code, there are many other examples. Programmers use throwaway code in unit testing to display application variables at different locations in the program. Database teams create one or more databases, long before the final database design is complete, to give application programmers access to the data they need to do their job. Throwaway code can also be used to link together programs to simulate an integrated system.

Some developers create entire test systems, occasionally rivaling the deliverable system in size. These test systems house test data in temporary test databases, run the test data against the system to be tested, analyze and report on test results, and then refresh/reset the entire test system so that the test can run again.

Near the end of the development cycle, a series of throwaway subsystems prepares the computer environment for the new system. Besides the conversion programs, there are back-out systems that, if the conversion from old system to new does not go well, remove the new system, replace it with the old one, and apply to the old system any data activity (adds, modifies, and deletes) generated by the faulty new system.

How much throwaway code is written for the average systems development project? Accurate numbers are hard to come by, but anecdotal information would indicate that in a few situations half of all code written during development is throwaway, with 20-25 percent a viable average.

How important is throwaway code to systems development? Well consider that almost every commercially available development tool—from code generators, debuggers, and testing tools, to GUI generators, cross-reference tools, directories, and more—started out as someone’s throwaway code. At some point, some smart entrepreneur thought there was an opportunity to share the best throwaway tools with the systems development community…for a price.

However, there are two problems with the current approach to throwaway software. They are:

  • Too Tactical or Ad Hoc

Throwaway code, with the possible exception of a conversion subsystem, is often considered the domain of the programmer. Individual programmers decide how much throwaway code they will create, when they will create it, and what it will look like. When they are done with it, if it is useful, they might keep it in a private library or folder; if it is only mediocre or worse, they might delete it.

  • Too Often Unplanned

Project managers work hard to ensure that all deliverables are considered when creating the project plan. The project manager needs to know exactly what will be delivered to the user to calculate costs and schedules with some hope of accuracy. This is a daunting task. Figuring out what has to be delivered, before what has to be delivered is defined, is difficult enough, but this is only the start of the project manager’s headaches. Because throwaway code can be considerable in size, perhaps 25 percent of the total code written, it needs to be accounted for when developing the project plan.

Sometimes the project manager is astute enough to include conversion software in the plan. Rarely are any other forms of throwaway code, such as back-out subsystems, included. The truth is that throwaway code is usually a planning afterthought.

There are two solutions to these problems that are, in fact, great opportunities to improve planning while reducing costs and enhancing productivity.

First, make throwaway code an integral part of the project and project management
The project manager should consider the need, development, and use of all throwaway code as both an integral part of the system being developed and its potential for reuse.

A famous French politician once said that war was too important to be left to the generals. Ignoring any potential wisdom that might be in that statement, it can be said with confidence that throwaway code is too important to be left to the programmers. Its status needs to be raised from coding tool to potentially important subsystems requiring project manager, analyst, and designer attention.

Management can delegate unit testing to programmers, but major issues, such as conversion, system testing, and back-out systems need to be given management attention.

Entrepreneurial wisdom should be applied to IT to propagate best practices. Routines that were deemed throwaway should be examined for their potential future use. Reuse can be as simple as storing no longer needed code “as is” or generalizing routines for a more varied and general adoption. This approach is not new to software vendors, who view their internal software libraries of reusable code as a critical systems development advantage that provides a foundation for better and cheaper products.

Any IT shop can do the same for little or no cost. It just requires the project manager, or someone delegated to the task, to visit the trenches in search of throwaway gems. Then project managers or IT needs to see that worthy routines are properly documented, housed, and their use encouraged.

Second, include throwaway code in the planning process
Recognize that throwaway code can be a considerable part of the overall systems development project and that its full impact is often underestimated. Ensure that throwaway code costs and schedules are bundled it into the plan, even if it is only exists as an overhead item.

Study the impact of throwaway code on past projects for more accurate estimates. Involve other project managers—be it with a quick coffee break or a formal meeting—to uncover organizational experiences with throwaway code and institutionalize the results.

Make sure that, going forward, throwaway code is an integral part of all post-project reviews. Document the actual impact of throwaway code on the project, not just what was planned.

This is an opportunity for the project manager to shine while improving systems development performance at little or no additional cost. Deals like this are hard to come by. The wise project manager takes advantage when they do.

This article is excerpted from Tillmann’s book ‘Project Management Scholia: Recognizing and Avoiding Project Management’s Biggest Mistakes‘ (Stockbridge Press, 2019).