The Lava Layer Anti-Pattern (2014)

Too many software charlatans with too big responsibilities (architecture&#x2F;strategy), with too many books read that were written by evangelists and way too little experience in whole software development lifecycle.<p>Write software, 1.5 year later update CV with fancy buzzwords you used, change job for better comp and repeat. Who cares how did the design mature?<p>They always have some method&#x2F;approach which is unparallelled in every metric, except it being reflected in reality.<p>Years of brainwash caused new developers to make strange looks if you use &quot;if&quot; statement or write comments in your code.<p>Also acting as if design pattern was some holy code instead of just a name for an approach to some problem (just normal code, but with name).

There is a concept known as Chesterton&#x27;s Fence - that you shouldn&#x27;t take down a fence someone else put up until you know why they put it up, or more generally if you don&#x27;t understand why something was previously considered a good solution to a problem, then it&#x27;s possible you don&#x27;t understand the problem it was meant to solve.

<i>Each wanted to re-write the application rather than maintain it, but the business owners would not allow them the resources to do it.</i><p>One trick I&#x27;ve successfully used to get around this is to basically work on doing that in what would otherwise be slack time, at &quot;background priority&quot;. Only when you&#x27;re done do you give the business owners the proposal, and when they object, say that you already did it and show them the results. Of course this works only if you actually do have slack time, which is normally a given in the sort of enterprise environment these abominations usually get created in; and you understand the existing application to a sufficiently large extent and manage to find a way to simplify it to a fraction of its current size while maintaining backwards compatibility, something that seems to be the exact opposite of what the leads in this story wanted to do.<p>&quot;It&#x27;s easier to ask for forgiveness than permission.&quot;

In my experience, it is very difficult to get a commitment for the effort to remove deadcode.<p>The problem is essentially invisible to everyone except maybe the dev who is dealing with a high noise-to-signal ratio as a result.<p>If it was a woodworking shop instead of a code repository, management would constantly see what a mess the shop is due to never being cleaned up properly.<p>They would never tolerate this because of the way it looks. The woodshop looks sloppy, half-assed and almost sure to be an inefficient place to do work, if it does not get cleaned up on a regular basis.<p>Because they cannot see deadcode in the repository in a similar manner, it is especially challenging to get them to care.

Code unambiguously defines &#x27;what&#x27; it&#x27;s doing, so I&#x27;m not sure what value technical consistency provides.<p>If anything, consistency hurts the capacity for developers to generalise their understanding of a system. Differences in representation ie. multiple perspectives, help people to develop their understanding of the underlying concepts of the system.<p>This is important because code doesn&#x27;t effectively record concepts, intents and oughts. These are things recorded within the context of the system. So the more context, usage and interactions available, the more opportunity for learning.<p>I think consistency is one of those things that sounds appealing and offers the illusion of making development &#x27;easier&#x27; but boils down to someone deciding by fiat that their poorly communicated representation of the system is correct and nobody else should add their own representations of the system to build up a useful level of context and understanding.

I’m surprised that tests are only mentioned as a way to squash bugs and not as a way to make refactoring faster. Just today I converted a large library into a service and brought in some endpoints from another service. The diff is several thousand lines. But I’m not too worried about bugs because we have decent test coverage.<p>I’m not sure why, but I really like working with legacy code (as long as I’m given some autonomy to improve it over time). Part of the enjoyment is the restraint, the humility when facing code that, despite not being squeaky clean, has racked up millions or billions of hours getting shit done. The code knows itself better than you do.

I once, for a short period, maintained web-application that had three different frontend frameworks (angular 1, angular 2, and one other I don&#x27;t quite remember), and four different javascript builds that had to be run to build the application. Apparently management prioritized the giving demos to investors, and changes to different frameworks were aborted halfway through.<p>It was completely impossible to work with. Each week the build failed for new random reasons. I hardly dared touch the thing.<p>This &quot;pattern&quot; is really a failure from multiple parties:<p>* Managing software engineers is an art, and you really need to understand what is happening to succeed. Only prioritizing short-term goals just ensures you&#x27;re going to fail in the long-term. Make sure you understand technical debt. The speed of work in bad code-bases versus good code-bases can be orders of magnitude in difference.<p>* Software engineers really need to use branches properly. Work that is halfway done should not be in the main branch. Consistency and simplicity is king here. Maintaining an old and new version of software for a while can be a pain, but it&#x27;s much better than maintaining a halfway converted application. Pressure from management is no reason to release stuff halfway done. And if you need to demo, release a specific branch.<p>Nowadays I don&#x27;t even ask to do necessary maintenance. It&#x27;s just part of the job. Always stick to the boyscout rule (leave things in a better state then you found it). Make your code-bases cleaner incrementally, and eventually you&#x27;ll be in a much better state.

I&#x27;ve coined this &quot;architecture archaeology&quot; at work. The further you dig, you find a new technology in use, corresponding with new technical leadership.

Struggling with this on a current project, except I’d say it’s not currently consistent. It already has “lava layers”, lots of bugs and unintended behavior devs struggle to reproduce in dev&#x2F;test. We’re debating rewrite vs refactor now. I find myself going back and forth between dogmatic and pragmatic approaches. Which maybe is a good balance to try to strike.

In other words: any incomplete refactoring is technical debt.<p>In case of considering a refactor always make sure you can finish it completely.