Dead Water
The phenomenon of Dead Water is well known to sailors who travel through regions of mixed salinity. First noted by Nansen, a ship will lose way and be unable to travel forward. If the ship is moving sufficiently fast, it won’t be hampered by dead water, but with slower vessels this effect can bring the velocity of the vessel to less than 20% of its effective speed.
What happens is that the ship looks to be in calm water. But there are 2 layers of water at work. The calm water is a layer of fresher water floating on top of more salty water. As the boat moves across the water, waves are set up in the lower level, and start to create large drag. In some cases this can even be shown to operate like a conveyor belt keeping the vessel from progressing.
Similar issues lie in the modernization and adoption of best practices within legacy organizations. We’ve all heard the benefits of [insert your best practice here], and seen how these practices work in various successful businesses. The overwhelming anecdotal evidence though shows that the work done to introduce new methodologies is, while worth it in the long run, beset with pitfalls and runs into patches of dead water.
Take for example the company that is trying to modernize a conservative architecture. Bringing in Automated Testing, CI/CD, Observability and modern container based architecture is greeted from the Top down with enthusiasm and even strong prioritization. Proof of Concepts are performed, single teams projects are done to show how the new practices and tools will work. Initial feedback is great, the adoption of the new CI/CD pipeline is definitely seen as being beneficial, the automated testing reduces feedback loop times to short enough levels that developers don’t lose context. Observability is put in place and instrumentation shows that the product can respond effectively to traffic patterns and the containerization allows for rapid response in scaling.
Of course there are one or two naysayers on the legacy systems, but nothing major, and even they (the recalcitrant minority) seem to be getting more on board. Some more teams adopt the toolset and the practices, the company is getting speed on this modernization lark, and then… suddenly, without warning (and likely almost impercebtibly) things grind to a halt. We find that there are systems that “we just can’t move yet” or “the work effort is too large to get these to the new systems”.
So what happened? In organizations that adopt new practices whole heartedly, we generally do not see this sort of stagnation. Sure, there is a large amount of inertia to overcome at the beginning of the adoption, but this initial effort pays off quickly. The business can market this as new initiatives, modernization of the platform etc. but will take a hit while new architecture is brought into play. In this organization though, the business took a much smaller hit (although there was some slowdown) and there seemed to be plenty of momentum to continue the modernization. So? How did we end up in this situation.
Dead Water causes more than just a slowness of trade or exploration. Dead Water has been thought to be one of the causes of Octavian’s victory over Cleopatra and Mark Antony at the battle of Actium. And there are parallels between this battle and the organizational inertia that we run into in retrofitting best practices.
Octavian had more but weaker ships. Cleopatra and Mark Antony had heavier, better armed weapons platforms. Octavian won because Mark Antony was inexplicably motionless for 3 hours and then when starting his charge, he failed to get speed. This meant that he had to completely change tactics and used methods for which his fleet was ill-suited.
In the organizational parallel, there are two layers of architecture — the new/modernized architecture and the legacy systems that are yet to be brought on board. A second parallel is clear too — the legacy teams (the recalcitrant minority) are smaller and weaker from a pure technology and business point of view. The clear advantage goes to the teams that are using more modern systems and practices. However, in our example, the legacy teams have succeeded in slowing the adoption of the new toolsets.
Again, anecdotally, the modernizing teams tend to adopt a different strategy, trying to insert their techniques into existing methods that the legacy teams are using. These practices, however, have prerequisites and without taking these into consideration, it is unlikely that the new toolsets and methods will be as effective as they could. Often, the organization remains in a kind of limbo state with the 2 approaches in competition.
The general solution to this problem is to let things “die on the vine” but this has myriad problems not least of which is the technical debt and maintenance cost associated with handling legacy tools, processes and product. This is akin to the traditional method of dealing with Dead Water — wait. It will go away.
Solving the problem in a way that will drive the company forward, provide a longer technical runway and create the ability to grow the technology, personnel and business is harder. It would appear that in general, there is some headway to be made. Rather than pushing new techniques into legacy processes, there is the possibility to take smaller slower more shallow strokes to provide headway. What this means is that cross-collaboration and revisiting the relationships that were created before the projects began becomes more important than the technology and tools.
As things start to slow down, it is important to work with the legacy teams or the late adopters to understand the pressures that they are under and to work with them to address those issues. These small steps still move the projects ahead, albeit at a much slower pace, and allow teams and personnel to gather speed so that once there is a renewed focus and critical mass, the remaining architectures can be brought up to date together rather than piecemeal.
Overall this analogy allows us to better plan for retrofitting, including planning for the likelihood of dead water in the organization.
