BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Architecture, Technology and the Lava Layer Anti-Pattern

Architecture, Technology and the Lava Layer Anti-Pattern

Leia em Português

This item in japanese

Bookmarks

Successive changes to architecture and technology throughout the lifetime of an application can lead to a fragile and fragmented codebase that is hard to understand and maintain, an anti-pattern named Lava Flow or Lava Layer, Mike Hadlow explains sharing his experiences of how and why this anti-pattern sometimes emerge.

Mike, a freelance software engineer, has often experienced this anti-pattern in enterprise software, especially in large, mission critical and long-lived software in connection with organisations having high staff turn-over. He has also found that it often surface from a desire to improve the software. To illustrate how this anti-pattern arises he has created a fictional story about an application, based on his experiences from numerous projects.

Development of the new application was started when the .NET platform was relatively new and a decision was taken to build a web based application on the ASP.NET platform and to adapt to e.g. Microsoft design guidelines by building the Data Access Layer (DAL) based on the ADO.NET RecordSet and exposing Datasets directly to the UI layer.

The application was released and after some time in use new requirements evolved and a budget was assigned for a new version. With a new lead developer critical to the DAL implementation and usage of Datasets a new design was decided. For the new parts of the system an object-oriented model approach was chosen with classes representing tables and code generated from the relational schema.

After a few years, with new developers working on the application not really understanding the two different models, one using Datasets and the other a type of Active Record pattern, yet another design was decided for the third version, this time using a domain model and an Object-Relational Mapper, ORM. A suggestion for a complete rewrite was rejected, resulting in an application with three different data access solutions and different implementations of the same type of function depending on during which generation it was implemented.

Although this was a fictional project, Mike often sees the same problem in real projects. In projects without a consistent architectural strategy and an unclear design philosophy, thus allowing for new design and technology choices, these new choices seldom completely replaces the old ones resulting in a system with archaeological layers revealing its history and the different technological fashions used. He believes that developers act in good faith wanting to improve a system but are lacking the resources needed for a rewrite, instead ending up with systems implementing the Lava Flow anti-pattern.

Mikes advice is to carefully evaluate any significant architectural or technological changes in an existing application, sometimes it may be better to favour consistent technology even though it might be considered old fashioned or legacy.

Rate this Article

Adoption
Style

BT