In-Depth

The Dilbert dilemma

• By Stephen Swoyer
• April 1, 2005

Almost everyone agrees the best way to keep a good application from going bad is to periodically retool it. Just as an F-15 jet aircraft is routinely stripped down and reassembled once it has logged several hundred hours of flight time, companies need to retool even their most durable applications. The F-15 aircraft that are in service today are more than 30 years old, but they continue to be as reliable, if not more so, than they were in the early 1970s. If only the same could be said for legacy code!

Not surprisingly, few organizations are willing to invest enough budget dollars to maintain their applications in the same way. If managers and corporate buck counters are almost reflexively opposed to large-scale rewriting, they’re only slightly more receptive to refactoring. The upshot, then, is that a problem application often has to become a multi-faceted Frankenapp before management is willing to do anything about it.

“It’s the old argument that you have to walk to work ten miles every day because you don’t have time to learn how to drive,” says Peter Scott, president of programming consultancy Pacific Systems Design Technology and author of Perl Medic: Transforming Legacy Code. This is not a reasonable position, and management needs to be made to see that, he asserts.

But as far as many veteran coders are concerned, management and programmers will never see eye to eye on this issue.

“I actually have come to believe…this type of application…[is] the inevitable outcome of placing low value on the actual production of code, and instead focusing on documentation artifacts that are out of date almost as soon as the characters are typed,” says Bill Pyritz, a programming veteran with a large manufacturer of networking and telecommunications solutions. “Our management is so far removed from understanding how code is actually written and structured that it’s not difficult to understand how these Frankenapplications come into being so easily and repeatedly.”

Michael Feathers, a consultant with Object Mentor and author of Working Effectively With Legacy Code, agrees that in some environments, particularly in corporate cultures in which waterfall predominates, you’re going to have little or no luck selling management on the idea of pro-active refactoring as a cost-saving strategy for killing Frankenapps before they run amok, so, why bother?

“It’s your professional responsibility as a developer to do these things, and you don’t really need permission to do it, so it’s really something you can do on company time,” he argues.

In waterfall-centric environments especially, it might be the only recourse you have. “I tend to second [author] Martin Fowler’s view that you pretty much don’t tell your manager,” Feathers says. “Assume responsibility as the development team for refactoring as you need to, and go forward with that,” he says. “It’s really hard to get management to agree to the re-architecting that has to happen over the course of a long-lived application.”

Of course, most coders already have pretty full workloads, and many are even putting in unpaid overtime on top of that. Programmer Woo, for example, recently ran the numbers and figured his employer is getting 8.9 hours per day out of him, not including a lunch break. So, to get to your kid’s baseball game in real time, one strategy is to build in refactoring as part of the upfront maintenance costs of any proposed development project. This won’t fly in many organizations. However, management tends to view production support (where robust applications go to die) as a negative cost. As a result, developer person hours are already micro-managed.

Another strategy, Feathers says, is to couch your pitch in management-speak. This has a chance of success, he suggests—especially in profit centers tasked with developing applications or services for outside customers. “You can say to them, ‘Sure there’s the first release, but what about the second, or the third? If this is successful, we’re going to be asked to offer a lot more additional functionality, and how are we going to accommodate that?’”

Perl specialist, Scott, doesn’t take quite so dire a view of the situation. “You’ve got to put it so [management] can see where it benefits them, and this means speaking in terms of TCO and ROI. Ultimately, it comes down to effectively making the case that you save money by doing it this way.”

Back to feature: It's Alive! The Frankenapp Runs Amok!