When I look at code that makes me think "why would anyone do it this way?" I remind myself: the programmer who touched this before me very likely had plenty of thoughts about fixing this code, but they probably had good reasons for not getting around to it.
That's certainly true of some less than stellar code I've left behind. It's not for lack of desire to improve it. It's from (1) having written code against a different set of requirements than what they eventually became, and (2) it ain't broke and I have plenty of stuff that is broken.
One of the things I’ve personally learned and been touting it ever since, is that it’s ok not to make perfect code in a hurry or when the real target is somewhere else, if the crude method solves the problem for long enough and is capsulated well enough and the intent of the crude solution is documented and it has tests. Documenting the intent is useful for the next programmer to understand, why the solution has been enough for the needs then and to quiet the DailyWtFs for the next guy poking the code.
By crude solution I mean half-hardcoded or not well generalized methods as the other cases are coming in a year or so. This is also a way to limit the scope and to achieve deadlines. What this means though, is that when new needs arise we need to go ba k and make them better later. Kind of managed techincal debt.
As with all debt, it's not necessarily bad to incur technical debt. You just need to know how to leverage the borrowed funds to turn an even greater profit so that you can pay your debt back later and still come out ahead.
Beginners let their mess metastasize throughout the system. Experts keep it contained to a subsystem. There may be a lot of mess, but each subsystem is messy in its own way, and can be dealt with individually.
While I agree this can be true in general, this is not often the case.
We do mandatory code reviews in our company, and at least a couple of times, I have received a comment which made me go "whoah, this is much better than my idea!", followed by a new version which is 10x shorter and way more reliable.
Being the author of the code in question, I can tell you with full authority that sometimes:
(1) no, I had no thoughts of fixing the code, I did not know it was non-optimal.
(2) no, I had no good reason for not getting around to fixing it. I had no special requirements that would justify my decision.
(3) yes, I just did not think about it. It is like searching for something for a long time and then suddenly finding it in the obvious location -- except this time, I did not find the obvious solution, so I almost ended up committing this huge code monstrosity.
I've had the opportunity to develop behind a "pioneer" at one company - one who developed software as it was needed in an emerging field. I'm grateful to follow behind and have the time to write new code using the old code as a guideline - most of the hard work was already done!
(4) nobody wants to pay for it (i.e. prioritize fixing existing code vs building new features). It only gets fixed when the system is in such a state that new features are nigh on impossible to implement. Until that level is reached, developers just absorb the cost of working with the legacy code base as an externality.
That's certainly true of some less than stellar code I've left behind. It's not for lack of desire to improve it. It's from (1) having written code against a different set of requirements than what they eventually became, and (2) it ain't broke and I have plenty of stuff that is broken.