You are preaching to the choir ;-)

And, we have great management. This code just had its tenacles in so many places they (management) were not convinced that the potential return merited the testing effort. Now that we are involved in a major re-write of the entire app, they have no problem with the re-factor.

>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.