Books by programming theorists often When they define 'complexity' as 'anything related to the structure of a software system that makes it hard to understand and modify the system,' they miss a crucial distinction: the complexity of a supermarket is not the same as that of a telecom company. The primary factor in complexity is functionality and requirements to implement, followed by non-functional requirements, the restrictions of the IT environment, and then the structure of the software itself. At this point, time becomes a crucial factor. You may end up with a creature that, after passing user testing and certification, has transformed into an unrecognizable monster despite your initial best intentions regarding length and clarity.
When code gets out of hand and outgrows its initial design, I tend to refactor it to a new design that better accommodates the requirements.
The problem I usually encounter is that whoever was there before me didn't do this. They just made a solution then added quick fixes until it became a monster, and then left. Now I first have to figure out what the code actually does, try to distinguish what it needs to do from what it happens to actually do, usually write tests because the people who write the kind of code I end up fixing usually don't write good tests if any at all, then refactor the code to something more reasonable.
This can easily take me days or weeks whereas the person responsible could likely have cleaned it up much quicker because they don't first have to figure out requirements by reading messy code. Then again if they were competent and cared about the quality of their work they wouldn't have left me that mess in the first place so I tend to just write it off as incompetence, fix it and move on.