“I don’t need a great developer. It’s just maintenance work,” says the experienced software manager. She believes software maintenance is simple, tedious and boring. Seasoned developers won’t be interested, so the logical choice is to hire a cadre of less-experienced and less-expensive developers. She may also worry that seasoned developers will try to innovate too much and break the system she needs to protect.
What this software manager and many others like her fail to realize is that excellent maintenance of large, complex software applications is a sophisticated enterprise, requiring experience, a strategic perspective, and a broad knowledge of the system and its architecture. Because they lack that depth of knowledge, the “army of novices” actually drives software maintenance costs up, and their lack of experience virtually guarantees the eventual decay of the system that software managers are at such pains to maintain.
Unskilled developers shun the most important aspects of maintenance. ISO/IEC 14764 provides a thorough definition of software maintenance, and it boils down to fixing bugs, enhancing functionality and upgrading components. The goal of software maintenance? Keeping the software system in a state of high integrity over its useful lifespan. The reality? Throwing more and more inexperienced developers at the system does exactly the opposite. Here’s why:
Overwhelmed by the software’s complexity, the rookie developers avoid touching the system at all, and fall back on procedure. When the software fails, they restart the system, apply data fixes to correct the damage from the fault, and dutifully wait for the next failure. When faced with non-trivial enhancement requests, they choose to build simple satellite systems that partially meet the requirement, creating a kind of a suburban sprawl of functionality. Architectural changes are avoided at all costs, leading to an eventual legacy code burden that can be fixed only by a massive replacement project—the kind of project that has the highest failure rate in the industry.
On the cost front, while the unit cost for the less experienced may seem compelling, the math does not work as the novice team balloons in size to meet the demands of the system. Consider this: 30 rookies x $80/hour = $2,400/hour, while 10 seasoned developers x $140/hour = $1,400/hour. Needless to say, a different approach is called for.
The ideal maintenance developer designs improvements. The ideal maintenance developer is actually one who is more skilled and experienced than the developers who built the original system. And because of that skill and experience, the right maintenance team is a fraction of the size of a conventional maintenance team.
With a smaller, smarter team, the sophistication and therefore the results of maintenance work improve markedly. The more experienced developers can decipher old code, design improvements that match the style of existing code, and plan major architectural changes. Because the highly skilled abhor repetitive work, they find ways to eliminate it through automation.
When faced with a bug, experienced developers fix it so that it does not return. When faced with a minor enhancement, they properly modify legacy code without creating new regression bugs. When faced with major enhancements, they understand architectural evolution and can reliably size and plan the work so that additional resources can be added for this new project (and then subtracted when done). They take ownership of the codebase and aspire to keep the system fresh and relevant.
We need to make skill and productivity—not unit cost (a.k.a. hourly rate)—the rule, not the exception. Are you choosing the “army of novices” approach over the experienced developer model? It may be out of habit, fear of the unknown, or in response to business pressure to “keep costs low.” Or it may be driven by a belief that maintenance is grunt work.
It’s time to see the light, reconsider your assumptions, and shift the model. In the long run, experienced developers save time and money, and they deliver results that far outstrip their novice counterparts. Their proactive approach ensures software performs optimally, and avoids the pitfalls of tactical, reactive fixes. You might encounter some resistance initially as you engage the experienced, but don’t worry: The results will speak for themselves.
Lawrence Fitzpatrick is president of Computech, an IT services consulting firm located in Bethesda, Md.
