Sometimes when we start a new job, or support a new system, we inherit some technical debt. I am not talking about server issues or backup management. I am talking about poorly designed systems, with problems from database schema issues to cursors that are un-necessary to sa rights used for everything to crazy triggers to completely un-normalized tables. There are functions with unbelievably complex queries and views upon nested views that will keep you up at night. The systems usually run, perhaps not very well, but they more or less do what they need to do. I think there are three ways I have seen people respond to these messes.

The first response is a passive response. This is the most conservative and somewhat reactive way of dealing with the situation. Basically, you don’t do anything. No table changes or investigation of the system. You certainly wouldn’t disable any users. You wait; when and if something breaks or if performance becomes a problem, then you focus on that issue and fix it. There isn’t really a comprehensive analysis of the system or any plan to rewrite to fix the mess. It seems a lot of people go for this response since it seems relatively safe. No ownership is really taken, just band aids applied. Minimum effort is needed. This is a safe response, but you still have a mess.

The second response is systematic. There may be minor schema and table changes. Each stored procedure, function, trigger, and view is analyzed. There is a carefully laid out plan to improve the code. Cursors are removed, perhaps indexes are added. These can be relatively safe changes. Certainly, there is some risk, but the essence of the system is maintained. More ownership is taken of the system and hopefully, it is pretty well understood how things are supposed to work. Significant effort is needed to accomplish this solution. This response is still pretty safe and hopefully, there is less of a mess, but it takes time and money to accomplish it.

The final response I have seen is nuclear. This response tends to happen when the system was so poorly designed, or it is so convoluted that it is pretty much beyond any hope of repair. I am sure you can think up some other names for this type of system. So you pretty much nuke it all and just start over. New schema, new tables, new everything. This can be particularly difficult if there is no one who truly understands how the system should work. This is a high risk solution, but there can also be high reward. Maximum effort is required, as a complete rewrite is needed. The hope is at the end of the project, there is no more mess.

Different arguments can be made for each of these approaches. I would guess you all could add a few more options from your experiences. I have seen each of these solutions applied at different times throughout my career, and there have been varying degrees of success. Very few people feel good about a passive response, but sometimes your hands are tied. Management doesn’t want to invest the money and effort, or they have no stomach for the risk. A full on nuclear response might be the best action in some cases. We all probably imagine we can do a better design than the previous person. Still, such an undertaking comes at high risk and cost.

So, my question to you today is: what have you done when you inherited a mess? What response was taken and how did it all turn out?

Join the debate, and respond to today's editorial on the forums

To list all modules available, use

Get-Module -ListAvailable

A plain Get-Module will list those modules loaded. The -All parameter shows all modules that are loaded with a bit more information. The -Property Available doesn't exist.

Ref: Get-Module - https://msdn.microsoft.com/en-us/powershell/reference/4.0/microsoft.powershell.core/get-module

» Discuss this question and answer on the forums