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 over time. You might not make much progress 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 don't know how often I find management willing to stick with the same person.

I think my experience has often been that organizations engage in short-term thinking. They just try to patch an issue and don'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 grow 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.