It's called Technical Debt. It's very real and costs the company money. Waterfall methodologies are a leading cause. Uncaring and/or untrained programmers are another reason. Refactor, refactor, refactor is a good way to do things. I've learned over the years that management doesn't understand the need to refactor, so you just build-in some refactoring time to your estimates and just do it. In the end, it ends up costig the company less money and reduces technical debt.

>Not just fuzzy, but the slimey, liquifying stage. Enough of that analogy.
>
>These methods look like they started off as a good design. Pass in a collection of controls. Iterate over the collection and set the control's backcolor if a condition is met. Then somebody added an exception, then another exception, then an exception to the first exception, then it seemed like a good place to stick some other functionality only vaguely related to the original requirement and on and on.
>
>Amazingly, it has functioned correctly, just a maintenance nightmare, VERY fragile. Unfortunately, we are a small group and getting management to agree to a rewrite (it is going to require alot of testing) was a hard sell as long as it wasn't causing serious problems.