by John Browne, on Nov 18, 2020 1:09:37 PM
Congratulations to SpaceX on successfully transporting four astronauts to the ISS. This accomplishment marks a significant turning point in the space program, and it also proves a vital point about dealing with legacy applications: that it's far far better to migrate them then to rewrite them.
Bear with me, it will all make sense.
Since the retirement of NASA's space shuttle program in 2011, all servicing of the International Space Station has relied on old-school Russian Soyuz rockets. A few days ago (Nov. 15), to great fanfare, SpaceX launched four astronauts in their reusable autonomous space craft, ending the government monopoly on manned space travel.
Consider the breakthroughs: booster stages that are not only reusable, but return to earth via a gentle upright landing on a drone ship; a space ship that flies, navigates and docks without a pilot; and space suits that are more Star Wars than Buck Rogers.
The SpaceX team got to this historic point by following an engineering practice of incrementalism, rather than a big-bang approach. This same playbook worked perfectly for the Apollo project in the 60s, where the goal was a manned mission to the moon. In that endeavor, the US started out with an enormous goal set by President Kennedy ("send a man to the moon and return him safely, within the decade") at a time when the space program was mostly known for failure--that is, making very expensive fire crackers to explode at Cape Canaveral.
NASA approached the goal with a staged incremental approach: first get someone into space and recovered (Alan Shepherd), then someone in orbit (John Glenn), then a new space ship (Gemini) to put two men in orbit and a "space walk", then three men in a larger vessel (Apollo) to travel to the moon, circle it once, and return safely. Finally, of course, in June, 1969, Apollo 11 became the first manned mission to land on the moon.
Incrementalism. Solve the small problems first, then move forward one step at a time.
SpaceX: First we build a rocket, then we see if it can land itself; then we see if it can land on our ship at sea, then we send an unmanned ship to dock with the ISS, finally we put it all together and send people up to the ISS. You don't take the next step until the current step is correct and reliable. You reduce the risk of any single step, and--perhaps most important--reduce the risk of the final objective.
Migration is incrementalism while rewrite is big bang.
It's significant that the Apollo program started with a space ship that could not go to the moon. All the money invested in the Mercury and Gemini programs did not build a vehicle that could go to the moon. So it's reasonable to argue--at the start of the program--why waste time and money on Mercury and Gemini if those vehicles can not go to the moon?
What good are they?
They can't achieve the goal we're chasing.
Money spent building Mercury and Gemini rockets and launching them is just money we could be spending building an actual space ship that could go to the moon.
That's a big bang approach. It's how you build skyscrapers: you don't start with a 10 story building and keep adding 10 stories at a time. You build the whole thing, at one shot.
So what's the difference between a moon shot and a skyscraper?
Generally we know how to build skyscrapers. In any large city in the world these are under construction virtually every day. You want a 70 story office tower in Seattle? Getting the approvals and financing is a harder problem than figuring out how to build it.
Rewriting software is a big-bang approach. Migration is an incremental approach.
I know lots of people will disagree because: Agile. With Agile, they think, we'll rewrite that legacy app in sprints, controlling the scope and risk of each sprint. And that will be incremental, not big-bang.
The large complex app problem
Legacy applications that matter tend to be large and complex. If they were small and simple they would have been rewritten years ago. No one in their right mind keeps a VB6 application that's 2 million lines of code around unless it's both high value and super complex. They aren't vanity projects or school assignments: they are mission-critical apps that grew by accretion, not design, over years of modification by a variety of different developers, all of whom had their own ideas of how to do things.
They have business logic scattered over a zillion entry points and conditional tests; logic that is reliable if opaque.
They have dead code that's not marked and so clutters up the actual working code
They have no comments, out of date comments, or incorrect comments from copy/paste operations from other modules.
But the thing is, they work. They do real, important work every day. How they work, and why they work, may be a mystery, but they work.
Recreating that reliability from scratch--Agile or no--can be overwhelming.
Don't take my word for it; let's go to the experts, in this case Gartner (from Use Continuous Modernization as an Alternative to Rip and Replace):
"In some cases, a single and sequential modernization program might be the most efficient approach in removing technical debt and creating a digital platform. However, there are important reasons why gradually transforming legacy applications to platforms is often a better option:
- Cost, risk and impact. In many cases, to rip and replace whole systems is too costly, too risky, too time-consuming and comes with a significant impact on the organization. Is your organization willing and able to accept that?
- We cannot wait. Even if you are willing and able to go through a rip-and-replace approach, it will probably take a year or longer to execute. Digital business cannot wait that long. It needs support as soon as possible. As IT, you are probably on the backburner of that digital business initiative anyhow.
- We cannot predict. It is difficult to predict what kind of services and data upcoming digital business initiatives will require. New and changing demand will challenge your rip-and-replace project.
Making application modernization a continuous and gradual process will provide a way around these three challenges."
Migrate, refactor, and strangle
Let's say you've got a critical, large, complex legacy app. You'd like a nice new shiny app to replace it.
But you don't have unlimited time and budget to do it.
Try this:
- Migrate the app to a new platform using WebMAP--say from PowerBuilder on the desktop to a native web application. Now you've got working code using current languages and components: HTML, Angular, Kendo UI, ASP.NET Core, and C#. You can actually hire people to work on this stuff. The app works because it didn't try to re-invent the business logic or the UX; it just re-platformed/re-architected the old app to the new language and platform. Put it in production and toss the old one.
- Refactor intelligently. Sure the new code isn't ideal, since it was a direct re-creation of the old code, but it's understandable and maintainable and most important: it works exactly like the original application. But the app has to be maintained, so when you need to touch some code, that's a great time to refactor that code. Maybe create a new class, or break up something complicated into atomic methods. Shift some globals to locals. Add some comments by way of documentation.
- Strangle: the strangler pattern is a way to move functionality out of a monolithic legacy app into microservices or even serverless functions, and then delete the legacy code. Eventually, the theory goes, the legacy code is completely "strangled" and can be discarded. Note: not everybody thinks microservices are such a great idea. That exercise is left for the reader.
Migrate, refactor, and strangle is an incremental approach to modernization. Deciding to rewrite is a moon shot. I'm not saying it won't work, but we hear from people all the time who tried it and eventually gave up, electing for migration as a more feasible and less risky (not to mention quicker) way to get off a legacy platform.
As my mother used to say at the dinner table, "Try it; you'll like it."
