When developing software, we’ll sometimes need to replace some code with something that can do the same job in a different way. There are several ways to do this, but one of the safest is The True Lies Pattern.

I didn’t invent this pattern, but came across it 10-15 years ago. I tried to find the original source without success.

The Pattern

When we have a piece of code that does its current job, but needs to change to support new requirements, we have two main options:

  • Refactor it

  • Rewrite it

This applies at many different scales: a small piece of code, a function or method, a class, a module, or an entire subsystem or system.

Long-time readers and those who have watched some of my talks or attended my workshops will know that I much prefer the refactoring option. However, there are times when a rewrite is in order.

One of the safest ways I know to do the rewrite is the True Lies Pattern.

To apply the pattern, we start by building up the replacement code off to the side while leaving the old code in place. Once we’re pretty sure it’s working, we start modifying the client code to use the new code.

This might involve adding a second set of instance variables to a class, or a parallel set of functions with similar-sounding names.

In the best situations, we use both the old and new code at the same time, and perhaps even compare the results of the two to make sure the new code is working. With website traffic, we can often divert a small but growing segment of the traffic to the new code as we gain confidence in it.

Once we’re sure the new code is doing what it should, we remove the hooks into the old code and then delete it. If we’ve had to introduce similarly-named methods or variables, we might want to go back to the new code and adjust some names here and there.

I even apply this pattern when I’m manually extracting a method or function. I create the new method/function header, copy (not cut!) the old code into the body, make any necessary adjustments, and only then replace the original code with a call to the new method or function.

On larger pieces of code, you can use something like GitHub’s scientist gem as described in Jesse Toth’s talk at RubyConf 2014.

When you’re applying this pattern to refactory legacy code, Justin Searls’ Suture gem can also help.

The True Lies Pattern might seem like an overly-strict or disciplined approach, but it keeps the code working all the way through the rewrite. After each small change, we should be able to run our tests and have them pass. There might be a brief moment when cutting over to the new code that something is temporarily broken, but we want to make that window as small as we possibly can.

The Source of the Name

The name of the pattern comes from the ending of the 1994 movie True Lies, starring Arnold Schwarzenegger and Jamie Lee Curtis. Without giving too much of the movie away, a section of the old 7 Mile Bridge in the Florida Keys is destroyed by missiles.

At the time I learned of this pattern, the urban legend was that the film’s production company had bought the rights to destroy part of the old bridge after the new 7 Mile Bridge had been completed, and that the scene in the movie was not just models and special effects.

According to the story, the new 7 Mile Bridge was built alongside the old one. Once it was done, the on-ramps were changed to take traffic onto the new bridge, and then the old bridge was destroyed during the making of the film.

Unfortunately, this really was just an urban legend. The truth is a little less exciting, according to this account:

The bridge that was blown up was an 80’ model of the 7 Mile Bridge. The old bridge (where they did the shot) was already “blown up”, when they opened the new bridge. The bridge had sections removed so that taller boats could pass thru without the need for a drawbridge.

Perhaps this is why the pattern isn’t as well known today, but it’s a good pattern to know and I still like the catchy name.