While lava is hot and deadly early on, it becomes hard to move once it cools down. The is the thinking behind the name for the lava flow pattern. This anti-pattern is one that occurs for more often than one would think and can be quite tricky to clean-up.
Defining the Lava Flow Anti-Pattern
There is nothing like a rant blog entry to give us a good definition for an anti-pattern. [Click Here to See The Page]
“Successive, well intentioned, changes to architecture and technology throughout the lifetime of an application can lead to a fragmented and hard to maintain code base. Sometimes it is better to favour consistent legacy technology over fragmentation.“
In my experience, the most common trait of the lava flow anti-pattern in projects is that several developers historically worked on them. Every developer has their own experience, and when they dive into a project with their approach as opposed to matching the current standards, then things become complicated. In the best case, it is easy to see that several developers wrote the code. In the worst cases, the lava flow pattern appears, and you have all sorts of technologies and halted attempts at a solution. It makes maintenance feel like wandering through a complex hedge maze.
Demos Gone Bad
While varied developers is a factor that contributes to the appearance of this anti-pattern, another common misstep is turning a demo or proof-of-concept into a product. Take it from someone who has written dozens of these such one-off programs in the past. There is often some ugly code and incomplete thoughts buried in the source. We rarely clean things up since we are under the gun and assume no one else will use that code. Unfortunately, there are times where the demo is good enough that someone decides to productize it. Put another way, when there should be a design and product created from scratch we sometimes skip those critical steps and build out an existing proof-of-concept. In these cases, we are building on a partial foundation or one that is not intended to be weight-bearing. That starts us into building a house of cards before we have even released the first version. Needless to say, this is not a recipe for success.
Correcting The Anti-Pattern
I would not do a solution justice without first mentioning ways to avoid this. There are a few considerations to keep in mind during your coding to reduce the risk of this.
- New and Shiny are not always the best. Do not throw out existing ideas and concepts in a project without good reason.
- Use version control to branch your theories and trials away from the code base. You can always merge them in later if they prove out.
- Understand existing standards and guidelines before diving into coding. You will be better served by understanding how things currently work rather than bringing your genius to the project in a vacuum.
- Maintaining a system takes work and can be frustrating. Go with the decisions made by those that have gone before you.
Now that we have those out of the way, we can talk about fixing a lava flow. It is not easy. There are often some pieces of the various technologies that still used and an essential part of the system. The first step is to pick one approach among the ones in the system and go with that. At least the new code will start to look similar. As you address technical debt and fix bugs, you can begin to convert the other approaches to your one choice. Make sure you keep this in mind during code reviews and the like so you can hold the team accountable for slowly making the corrections and merging the varied approaches into one.
