Stairway to SQL PowerShell Level 10: Getting data in and out of SQL Server using PowerShell (2021-12-08)

Daily Coping Tip

Leave a positive message for someone to find.

I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate.

For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours.

Worse Before Better

There was a thread on Twitter on career longevity and fixing issues inside an organization. IT notes that often there is a problem and someone is assigned or hired to fix them. Often when someone starts to dig in, they can fix some things and reduce the pain. That's good, as things get better.

However, as you gain more knowledge of the issue, sometimes you realize there are more fundamental problems. If you try to fix them, you might make things worse. This could result in a repeat of the process of worsening and bettering of the problems if new people are constantly assigned when things get worse. If you stick with the person that is working on underlying problems, things get better over the long term.

I think that's often been my experience. Short-term thinking, just trying to patch an issue, doesn't necessarily make things better over time. I certainly saw this with supporting Windows systems in the 90s. We often rebooted machines first, which "fixed" the problem. At least for then. Often the issue would repeat, but customers could reboot their own machines.

Is that the right approach? It could be, if a long-term fix requires lots of resources, perhaps a regular set of reboots from people is a better tradeoff. In a more complex system, usually, we find someone fixing a short-term software issue with code that is less reliable, or even less upgradable in the future. How many times do we see code that has a comment to "not touch this" or a note that the last developer didn't understand this, but it worked. We end up with spaghetti code that no one maintains, doesn't want to touch, and it inhibits our ability to grown and react to new requirements.

Good fundamentals make a difference in how we build and maintain systems. This is especially true in databases, as we have to live with their design for a long time. We need to be agile, but we should apply good database modeling and integrity practices as we do so. Making quick decisions on how to add something to a schema is fine, but do so in line with best practices and an eye on the future.

Steve Jones - SSC Editor

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