Legacy Code Conversion Service

Companies that have legacy code often want to convert the code. They want it to conform to modern standards (for example, web services, JEE, etc.). They want it to be easier to work with (structured, layered, Mavenized, etc.). They want it to interoperate better with other internal and external systems.

Companies that have legacy code often have made an effort to replace, rewrite, or refactor the code. Often these efforts were paid for by reducing funding for new-product development. Often those efforts have failed, leaving them with the same legacy code they started with, behind in the market, and frustrated.

A consulting firm could specialize in making legacy-code problems go away for companies, for a handsome fee.

The consulting firm would not need to advertise. Contracts would come to the firm through referrals from CEOs, CIOs, CTOs, and boards of directors of companies that had their legacy-code problems fixed by the consulting firm.

The consulting firm would not need to be big. It could consist of a small team of experts, working remotely. There wouldn't even have to be a central office.

The consulting firm's engineers would use powerful analysis and refactoring tools running on 64-bit machines with huge amounts of memory. Some of the tools could be from open-source projects, and others could be developed internally. The tools would not have to be polished, with nice GUIs. They could be command-line based. They would just need to do the job.

The consulting firm would only need two or three contracts at a time to be making money hand over fist.

Because maintaining source-control history while massively refactoring code is a pain, the consulting firm should charge extra (a lot extra) to do that.

The best thing about this idea is that a consulting firm could describe in public exactly what it plans to do, and how it plans to do it, and nobody would compete with the firm. Even if somebody did compete, there would be more than enough work to go around.

Why is that? Because engineers don't want to work with legacy code. Legacy code is a dead end, they think. Cream-of-the crop engineers especially don't want to work with legacy code. They want to create. They are artists. Maestros.

Competent engineers who are willing to work with legacy code are rare, which leaves the field pretty much wide open.

Which is odd, really. There is a lot more legacy code in the world than new code (and new code has a way of turning into legacy code over time). Most code is legacy code. And it can be quite satisfying to convert troublesome code into good code.

Super-tool For Refactoring

One of our projects at work involves refactoring the code into layers (UI, business logic, data, service, and so forth), and then vertically into components within each layer.

In many cases, the work involves mechanically moving classes to their correct layer, splitting classes, moving methods, and sometimes adding listeners or Spring initialization to remove upward dependencies.

The work is tedious. There's nothing particularly creative about it. It's just a slog through a million-plus lines of code.

Refactoring tools are available, but they are basically tedium reducers. They automate mechanical transformations at the lexical level, but they don't understand anything.

I want more. A lot more.

I want semantics instead of syntax.

Somewhere in the Platonic realm, our program exists in the form of its true, perfect nature. I want refactoring tools that make it easy to move a program towards its ideal form.

Imagine standing in front of a big display like the one in Minority Report, lighting up a long sequence of nested if/then/else/case statements, and selecting "Infer Rules Engine".

Imagine pointing to other sections of the code and being able to select operations such as:

"Infer State Machine"
"Recode Without Side Effects"
"Remove Programming By Exception"
"Replace Static Initialization With Spring"
"Make Stateless"
"Extract Declarative Configuration"
"Replace With Annotation"
"Manage In Cache"
"Substitute Composition For Inheritance"
"Reimplement With [Name of GOF Pattern]"
"Extract To Presentation"
"Canonicalize To JEE"
"Promote To Web Service"
"Internationalize"
"Make Testable"

all while maintaining source-control history.

(Moved from http://jimshowalter.blogspot.com/2010/03/one-of-our-projects-at-work-involves.html.)