A time to migrate
Not all applications come to life in an organized manner…
Requirements? Joe, the salesman at ABC Ltd., needs a report that correlates the volume of tea sales to the amount of rainfall reported in the county. Design? Just a sketch on half a sheet (complete with tea stain). Then Mike, the engineer kid who hacked computers in high-school, crafts a simple script that does the job. Testing? Er, just tell Mike if you have a problem, he’ll fix it in five minutes - smart kid!
Time passes and ABC Ltd. has grown into ABC Inc. Joe is now leading the sales department and Mike has an MBA. The script has grown as well, with various contributors adding up to a veritable jungle (Dan liked FoxPro, Louise only knew Oracle Forms). The reports still get the job done ? they correlate tea with weather, galoshes with elections and so on. But the inner workings are undocumented, sometimes poorly written, virtually impossible to understand for the uninitiated. Something should be done, but nobody dares voice the thought ? if it ain’t broken why fix it, right?
This slightly cartoonish scenario is not that uncommon. Most applications live somewhere in-between total control and total chaos. Most of them will grow over time ? the better they perform, the more features get added inside. They will be all things to all people, and the new things will have to be put in quickly. There’s no time to plan refactorings, redesigns ? the users want the stuff yesterday, the managers are pressuring, the developers do not risk their necks when deadlines are looming.
Technology changes too. From mainframes to dot-coms, in not so many years. Applications need to interface with everything except the kitchen sink (?in fact, if we use JINI…..?). They need to run fast, to scale well ? maintainability is inevitably pushed into the background. Until the whole thing is like a card house ready to collapse when adding this one more little feature.
Finally, after the new SOAP module causes havoc, someone decides enough is enough. Resources are budgeted for a major re-engineering. Or better yet, a complete rewrite with a change of programming language(s), since Mike’s scripting language of choice was not meant for ERPs and nobody knows FoxPro anymore ? not even Dan, who became a wandering monk.
I’d hate to be in the shoes of a team that attempts to accomplish so many things at once. And is burdened with high expectations as well ? from all stakeholders including the users who are familiarized with the old application even if they keep groaning about it. ?Software migration? is not a syntagm to be spoken lightly, it makes veterans shudder with unpleasant memories. If somehow the process could be more controlled, to keep the managers from going gray. If somehow the transition to another programming language/technology could be separated from the structural/conceptual changes, to keep the developers from going gray. If only the resulting application would look and behave at least passably similar to the original, to keep the users from going gray.
But that’s an idea for another post. Joe wants to correlate UFO sightings with chocolate sales, so I’d better run and write him Yet Another Ruby on Rails Tool ;-)