3 ms·
This fear is well-founded. Changing a system is a lot riskier than leaving it alone and building things around the periphery. Changing it requires a deep unders
by cle 6y ago
This fear is well-founded. Changing a system is a lot riskier than leaving it alone and building things around the periphery. Changing it requires a deep understanding of the implications of the changes, the impact on consumers/clients/other systems, etc.
Doing that continuously does accrete complexity. But there is often a higher cost to fixing a problem rather than working around it.
- lukifer 6y agoWhile you’re completely correct, I’ve also observed an anti-pattern where people become afraid to touch load-bearing code if it “works”, compounding over time into a brittle codebase and piles of hacks to work around shortcomings in infrastructure. Assuming it meets the risk/cost/reward trade-offs, I’ve found it’s preferable to rip the bandaid off and refactor ASAP, rather than allowing “fear-driven development” to take root. (Obviously, a robust test suite greatly lessens the risks.)
- cle 6y agoI completely agree, and I do the same thing too. If there's something that people are scared to touch, I immediately want to change something fundamental in it so we can get un-scared of it. I'd rather have a controlled demolition than a "rapid unscheduled disassembly".
- lukifer 6y agoSuperb analogy!