An example of technical debt and it's consequences.

Much has been written about "technical debt" and the need for regular refactoring. The concepts are well-enough known so I won't bother rehashing them. Unfortunate some organizations still seem quite ignorant of these concepts and pay the consequences. Here's a real-life example...

One former client runs a critical business system on a prototype that escaped into the wild. The main database table contains 90+ columns, resulting in large performance, scalability and integrity problems. Unfortunately, no one with authority would agreed to improving the architecture before the business was experiencing repeated outages and a massive crisis. These outages cost the company millions of dollars in lost revenue (no exaggeration) and led to scores of customer complaints. This situation could have provided an expensive lesson, but the IT executives didn't actually learn anything. Once the system was "stable", very few resources were allocated to improving the system's design or implementation.

Personally, I believe guerrilla refactoring is appropriate under such circumstances, but that's a story for another time.