4 ms·
Sometimes you have a root cause deep in the architecture. As long as that cause exists you will have to work around it. Each work around will have to be removed
by xupybd 4y ago
Sometimes you have a root cause deep in the architecture. As long as that cause exists you will have to work around it. Each work around will have to be removed if you ever fix the root cause.
I saw this as a developer and had thought it was better to just leave the architecture alone and keep the work arounds as tidy as possible. Then I started working in manufacturing, a production line has many similarities to a running program, and saw the true cost. We fixed a root cause at the beginning of the line and all the work we put into working around the original problem was more of a mess to clean up than fixing the root cause.
I'm now a believer in trying to fix the source if possible.
That said a legacy code base with no tests is less likely to get a structural change from me.
- shkkmo 4y agoIf you are implementing a workaround, then that is a potential opportunity to solve a root problem deep in the architecture. The point being made is that going in to fix that root cause because you think that there will be a need for workarounds in the future is premature and can cause problems and unnecessarily break working code.
- thaumasiotes 4y ago> Each work around will have to be removed if you ever fix the root cause. Do they? I feel like many workarounds will just hang around, checking for situations like inconsistent state that no longer arise. You might be better off removing checks for conditions that no longer occur (or not...), but it's not exactly urgent.