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.
In projects that allow for new design and technology choices, these choices often don't completely replace the older technologies. These half-made changes result in layers that increase maintenance cost and overhead.
Often these changes are well intentioned. New engineers, management, scaling, etc. can all exacerbate this problem. A newer developer will try to improve a system but don't have the resources to rewrite large parts of the system.
It's important to evaluate significant architectural or technological decisions when dealing with an existing system. The justification of 'refactoring to the new pattern over time' may not ever completely materialise. What will the application look like with two different ways of doing the same thing?
Sometimes it is better to favour consistent legacy technology over fragmentation. [[20220328112803-choose-boring-technology]]
Also known as 'lava flow'.
[[antipattern]] [[architecture]] [[concepts]] [[migrations]] [[refactoring]]