In big companies and big outsourcers it often happens that projects are always broken down into small pieces, measurable, how quick. Training in new technologies, new languages, takes bites out of budgets. How quick can you get this done, and forget about modernizing your code, it’s not budgeted.

I sympathize, why fix it if it ain’t broke, and you’ve been taking the bugs out for thirty years, and you don’t want to do that again, but think about that. Like you have a hundred programs that access several files, each file in almost all of them say, and when you have to expand the amount file you have to change 50 programs and recompile the other 50.

Brace yourselves, your dollar amount fields have a high probability of a need for expansion soon.

And what is your company going to do in twenty more years with a change to your OCL you run with STRS36PRC, after all the guys are gone that used to know what to do with a matching record indicator and all that?

On a recent iPro or MC-online article somebody mentioned a study that showed 60-something percent of developers’ time is now spent on maintenance. Tools that make maintenance easier are great, and there are some tool sellers that address that (like Databorough and Hawkeye). But I think that many companies would be well served by a well-planned, minimally disruptive, stepwise move toward modernizing their code base. Things like breaking up the monolithic order entry programs into small pieces, replacing the in-line routines in fifty programs that access the same customer information by external routines, and so on.

ROI? Sometimes real hard to calculate, but if you can cut down maintenance on the other end by even half, then what would you say?