One source of rather nasty incidental complexity is the evolution of code in response to changing requirements.
Original code may have been well structured, with little incidental complexity. Then, over time, requirements change, and edits to code are made to accommodate them. If multiple changes like that are made incrementally, without revisiting the overall design from scratch, it is easy to end up in a situation where the code is completely mismatched in its design to the current version of requirements. There are bits and pieces that are only there because in previous versions they corresponded to the inherent complexity at the time. Fear is likely to get in the way of cleanup — “it looks complex, and I can’t figure out the reason why it has to be that way, so better leave it as is”. This is a dangerous, but very common, way of thinking.
The solution is to proactively simplify the code. If at every incremental change to match the updated requirements, you pay the small price of making sure there are no leftovers from previous versions, you are always keeping the code at inherent-complexity-only level.
So don’t meekly tack on, but bravely restructure to keep incidental complexity at bay.
Comments
Post a Comment