How are university campuses like healthy software?

(or The Importance of Refactoring Software)

by Leon Miller-Out

Great software is like a university campus. Over the years, new facilities are added, and old ones are renovated or replaced. If the entire facilities budget goes to adding new buildings, the campus will begin to sprawl, and the unrenovated, older buildings will become decrepit.

Imagine that a new sports center is built. The older, smaller sports center becomes redundant and unused. If the older building is not removed or renovated, it eventually becomes a liability, a blemish among the better-kept, newer buildings.

When we build software, we often find that new features make parts of the existing system obsolete. Sometimes we have time to remove those parts right away, but other times the budget or timeline prevents this from happening. This older code, like the old sports center, must be removed to keep the whole system healthy.

Some older buildings can be renovated instead of being removed. Just like the renovation of old buildings, we can often use newer tools and techniques to improve the implementation of an old feature, resulting in a system that works better and is easier to maintain. We can also leverage much of the work that others in the open-source community have shared with us, by upgrading our open-source software packages from time-to-time. Keeping up with these updates results in healthier software that can benefit from the latest development practices.

Just like the facilities planners and staff at a university, software developers need to allocate a reasonable portion of the budget to chores like renovations, cleanup tasks, and upgrades. We think that 10-20% percent is reasonable for most projects, depending on their age and overall health.

Since we track the time we spend on these chores (as opposed to work on features and bugs), we can tell our clients whether or not we think we're spending enough time doing this important work. We ask our clients to empower us to spend a certain percentage of our development time working on chores of our choosing. The end results are:

  • Decreased development costs (as new features have to deal with less old, funky code)
  • More reliable software (since we can do the best work we know how to do)
  • Happier, more productive developers (we work better when we're allowed to care properly for our code)