Related a little to my post “The Cost of Cleverness” as complexity is associated with cleverness but one can have complexity without cleverness. Imagine a non-trivial function repeatedly patched by different developers without anyone taking ownership and rewriting it. An example of mess might be a database with many probably redundant tables in it, not complex as such but certainly messy.
What I’m driving at is that both complexity and mess share the same unfortunate trait : they make things more difficult to understand. This difficulty can be conditional. If you are the one who made the mess or you can talk to the person who made it your understanding may not be so impaired.
So far I imagine few would disagree with what I have said. You should clean up the database/code in the same way you should write useful version control comments, use non-depreciated libraries, floss etc.
I’m going to be more specific. Not taking the time to reduce complexity and mess ultimately makes it difficult to make strategic changes to the software. As pointed out in The Mythical Man-Month :
“Lean, spare, fast programs are almost always the result of strategic breakthrough, rather than tactical cleverness … More often, the breakthrough will come from redoing the representation of the data or tables. Representation is the essence of programming“
This is very insightful. If strategic breakthroughs are not possible the software is in trouble, stagnation and/or rebuilding from scratch are on the cards.
It’s the old urgent vs. important clash, there is always something urgent that has to be done. My point is that unless you’re planning on abandoning the software in the near future then urgent has to be balanced with cleaning up of complexity and mess even if there is no immediate benefit.
It should be noted that the coherence we’re aiming for can clash with what might seem best from a purely technical point of view.
Let us say there are two different methods of loading objects from a database, A and B. Both work well enough but B is a bit better, maybe better error logging or something like that. Of course it makes sense that using all B for loading objects is better than using all A but it does not follow that a mixture of A and B is better than all A as this is less coherent and harder to understand.
Practically speaking to move from A to B there may be a transition period where A and B are mixed but this should only be entered into when there is a clear plan for A to be removed. It is only when A is removed completely that the improvement is really realised because only then do you get the benefits without the often underestimated cost of incoherence.