3 ms·
In practice it isn't even that much more likely to break, or even add features to. The code is just much uglier and more complex than it could be, and probably
by Scarblac 3y ago
In practice it isn't even that much more likely to break, or even add features to. The code is just much uglier and more complex than it could be, and probably slower. But it runs and keeps running.
Most of the time those business types are correct on this.
The only thing is that once the original team has moved on, then if the code is too complex, it can become almost impossible to change.
- ilyt 3y ago> Most of the time those business types are correct on this. If you can call it making problems after they leave "being correct".
- malfist 3y agoIt's a hard balance to strike. On one hand, the code is ugly and difficult to understand, but it has that ugliness for a reason, it's solving edge cases that you don't remember and a rip and replace is always expensive and no guarantee it won't devolve just as quickly. How do you strike the balance of the dev team wanting to fix unbroken code for long term health, and investing in new features that grow the business. Personally, I am biased towards encapsulation as a means to handle a lot of these types of tech debt. Wrap the old stuff in an orchestration layer and build new features with the orchestration layer in the middle. It's a bit of sweeping the dirt under a rug, but it also gives you a real solid base for later coming back and cleaning up the ugliness if it's really needed by giving solid contracts between the consumers and the orchestration layer and the legacy system and the orchestration layer.