Creating and Shipping a Chimera

  6 minute read  

My product is written in the wrong language!

Legacy systems tend to be old, and thus written in languages and frameworks that were available at the time they started. It’s no one’s fault, but the code is in the wrong language. This causes:

  • Slow development.
  • Difficult testing - my tech predates the TDD movement.
  • Reinvention - libraries for new techniques are written in new languages.
  • Difficult hiring - my tech predates most developers.
  • More bugs - my tech needs more code, so more mistakes happen.

Examples of port projects I have done include:

  • Port ColdFusion to ASP.Net MVC.
  • Port Ruby on Rails to Java, then Java to Scala.
  • Port JS + jQuery to Vue.
  • Port VAX to C#.
  • Port Cobol to C++.
  • Port Delphi 5 to a mix of Delphi 10.3 and C#.
  • Port desktop app to REST services + HTML front-end.

We may be changing language, version, framework, or execution environment. They all present the same challenge in the end. There is no obvious way to increment across the boundary. It seems like we have to move the whole program at once, and that’s not possible.

If we were to write the program now we would make different choices. But we can’t afford a rewrite. Now what?

Port Your Product By Using a Tame Chimera

I will, of course, recommend an incremental approach to the port. That means that we don’t just do one piece at a time, we also ensure two things. First, we can pause at any moment to implement - and ship - a feature. Second, any commit must be no worse on  any of the qualities listed below.

  • Bugs
  • Amount of functionality done in the old way
  • Testability
  • Testing
  • Functionality

As a result, the quality improves no matter what you measure. Just like racheting a nut, it only goes in one direction.

The fundamental engineering problem is to create a system that allows me to improve any one of these measures without moving any of the others backwards. All those systems are chimeras.

A chimera is not two animals, it is one beast with traits from two animals. Rather than creating two programs, one based on each technology, we create one program that contains both.

But chimeras can be nasty. We need a  tame chimera. We need to:

  1. Limit the number of animals we are combining at once, preferably to 2.
  2. Modify our delivery process so that we can ship two animals, each of which has no visible elements of the other animal.
  3. Ensure we can change any part of the body from either animal to the other.
  4. Transform our initial one animal to our chimera as quickly as possible - preferably in less than a day.
  5. Ensure each change in the body of the chimera leaves the original animal better.
  6. Be able to stop at any time and abandon our desired second animal, going back to simply an upgraded original animal.
  7. Have a tool to identify all the parts of the chimera and which come from which animal so we can choose which one to change next.

This  month’s recipe shows you how to design your chimera:

  • Pick your port strategy
  • Implement technical capabilities to support the port
  • Visualize the current status and progress to support decisions with data

The result is a tame chimera. You can incrementally get from your current product to your new technology. You minimize cost and risk, while delivering value early. Your port project will capitalize on early wins in order to accelerate as it goes.

Access the recipe to Port Products as well as other recipes coming in the future!

Port While Shipping

Your tame chimera will be able to ship at all times. Everyone on the team will be able to orient using data without explicit coordination. In other words, data replaces meetings. As a result, your entire organization can work simultaneously on both the port and feature development. Each team can make local decisions that are globally optimal. Management can see the results and choose when to take strategic actions without asking the teams for status updates.

Benefits:

  • Leverage new technologies and existing domain knowledge together.

  • Stop the port at any time, continuing product dev with the value you already shipped.

  • Clear visualizations support decision-making with cost and risk data.

  • Data informs management when to make strategic funding changes to optimize the project.

  • On Revitalization Projects:

    • Gain advantages of new technology from the first sprint forward.
    • Features accelerate and guide your port.
    • Port progress accelerates future features.
    • Know which features will be accelerated by the port, depending on how you sequence them.

  • On Cannibalization Projects:

    • Release the new product earlier and do Lean Startup.
    • Port speeds up delivery of non-core functionality.
    • Old product continues improving and provides funding until new product outcompetes it.

Downsides:

  • The port still has cost. You will need to spend time each increment to move some functionality from the old tech to the new before you can start leveraging it.
  • Your port will require alignment from the full product organization. One dev team alone cannot succeed. You need executive sponsorship as well as on-the-ground expertise.
  • Making decisions based on data can be a cultural mismatch for companies that are used to predictive plans and cross-team coordination. Changing the culture will require strong executive sponsorship and middle management support.

Demo the value to team and management…

Show three things at your sprint demo:

  1. Example: The shipping product with the cross-technology function call spike.
  2. Progress: Your progress dashboard.
  3. Impact: Use the drill-down viz to re-estimate a feature that you intend to do in the new technology.

The example portion is obvious; however, progress and impact require some explanation.

Example: Cross-Technology Call

Notify people that this is a bit of a techie demo. Then open the source for the place where you are calling between languages. Show that if you click a certain thing, it will round-trip through the new technology and then do something visible. Then do that. This also shows that performance is not utterly terrible - milliseconds, not seconds.

Progress: Progress Dashboard

Gather at least a week of data. Improve the data gathering across the week, showing how there is less and less unknown. Show the dashbaord and how you can use it to answer questions about current status. Use it to describe your progress through the week - whether you ported anything or not.

Impact: Data for Planning

Take one already-estimated future feature that is highly impacted by your technology and also integrates with existing functionality. Open up your drill-down dashboard and explore the code which is likely impacted by this feature. Describe how you would alter your estimate if various parts of the code were in the new tech vs the old.

Optimally, you can find a part of the code that would be much simpler in the new technology. You want something that is fairly easy to port, yet makes a big difference in the feature. Modify the feature to including porting that piece, and then modify your estimate accordingly. Show how the dashboard and the project give you the confidence to plan for features that touch both old and new technologies.