The Lava Layer Anti-Pattern

Good write-up. I've been observing this phenomenon for years and I think that one of the main causes is poor cost estimation by developers (or, often, no cost estimation). The new project lead asks management to allow him to re-write the project. It's a 10 manyear task so the management declines. At that point he decides to do the changes in gradual manner, completely ignoring the fact that it's still a 10 manyear task, while, realistically, his team can spend…

Too many software charlatans with too big responsibilities (architecture/strategy), with too many books read that were written by evangelists and way too little experience in whole software development lifecycle. 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? They always have some method/approach which is unparallelled in every metric, except it being reflected in reality. Years of brainwash caused new developers…

You don't have to have staff turnover for this to emerge. If you just keep teams starved of resources so that they're working on keeping the lights on, then escalations, and then berating them for barely ever delivering features, then they'll have zero time to address tech debt and you'll build up lava layers over time. A section of the codebase will get so bad and escalations or features will demand it get done better, so it does, but then…

This one's a tough one - I've worked on a number of existing (legacy/non-greenfield projects) and on most of them I've just gone with the flow (do whatever the current version does) and that was the right thing to do because they were huge codebases with lots of people working on them. Sometimes codebases do need a v2 though, and doing it iteratively seems like the safest approach, but it's easy to do a v2 just because there are multiple…