Voice of the DBA

Category: Editorial

  • Continuous Learning

    It seems there’s quite a dichotomy in the technology workforce. On one hand I hear about the Great Resignation where many employees are leaving their jobs because of RTO (return to office) mandates or some other dissatisfaction with their job. On the other, I’ve seen quite a few people who were laid off and are struggling to find new positions. On the third hand, there is no shortage of companies who report they are struggling to find and hire talented people for some positions.

    I don’t quite know what to think, but I do know that employment seems to be harder to come by. If you are looking for a job, I believe you need your own sustainable learning plan. If your organization can’t find qualified talented staff, then the organization definitely needs a continuous learning plan.

    I saw a piece on creating a continuous learning culture, which seems more suited for managers than technology workers, but there are a few good pieces of advice. First, set some goals. I write about this often, and I’ve seen others recommend this as well. Think about where you could improve your skills, and where you see demand for skills, and then start working backward on a plan to gain those skills. Think about where you want to be in 6 months or a year and build a plan to get there.

    Another good piece of advice is to learn within your flow of work, which often means spending a little more time deepening or broadening your skills in an area where you are already working. If you’re writing a query, analyze the plan and reads and see if you could tune it to run more efficiently. Read about those skills and practice them, which deepens your skills. If you don’t know much about query tuning, then broaden your experience and learn about a new operator, new index, new hint, and experiment. Then you have a wider view of what possibilities there are in query tuning.

    More importantly, build the habit of curiosity and experimentation, which is what will help you drive continuous learning throughout your day. It’s good to look at new things, but don’t forget to sharpen your existing skills, practice being better at the work you already do, and find a balance that ensures you are growing while still meeting your other commitments, both at work and away from work.

    There’s an old joke that if you train people they might leave, but if you don’t train them, they’ll stay. For organizations struggling with talent, embrace some investment in current employees, at least those who have potential. Grow them and you might find that the person you’ve been struggling to hire is already working for you. They just needed a little boost.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Why Would You Do That?

    I was listening to someone at Microsoft talk about their product recently. I can’t disclose which one it was, but lots of people use this product and are impacted by changes. The particular thing that caught my attention was that the presenter noted there was a breaking change in the new version for some people. This wasn’t a huge change or one that would affect a lot of people, but it was a breaking change for a few.

    Another attendee asked this question: I would tend to do xxx instead of what you showed, so why would you do this?

    It wasn’t an antagonistic question, but more curiosity. However, it was a good question since any changes that cause breakage can be disruptive to other people. The thing I noticed was that the questioner’s frame of reference was completely different than the presenter’s. The questioner couldn’t imagine writing code in this way.

    As I work with more and more customers, I find that many of them get tunnel vision in that they approach their work or code in one of a few ways and don’t think widely about other approaches. In general, I think that’s a good way to work as we ought to use patterns and avoid anti-patterns in our work. The more we all code in a similar structure and style with the same patterns, the easier it is for any person to maintain the codebase (or infrastructure).

    Of course, we have to be willing to add new patterns when we find them and drop older patterns that no longer work (and perhaps refactor the code). That’s another hard thing for humans to do. We rarely want to let go of patterns and who has time for refactoring?

    At Microsoft, they have to consider lots of different ways to look at code. I saw awhile back one of them writing that building Windows was like ordering pizza for a billion people. You’ll never get it perfect and someone will always be upset. I get that. I couldn’t imagine making changes to something like Windows, where every little thing upsets some group of people and sometimes those are a very loud minority.

    Many of us approach the world in similar ways, and we can appreciate or understand small differences. When we meet someone who sees things very differently, then it becomes hard to reconcile their view with our own. In code, this often means we want to use different patterns than others, which creates a less maintainable codebase.

    Communication continues to be one of the hardest parts of building software (and most endeavors). Part of our communication should be to try and understand others’ points of view, get them to understand ours, and come to a shared understanding of how to approach problems. That shared understanding is what helps us build better teams.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The Pervasive Nature of Open Source

    This week there was a headline that said “Open Source Software Powers 96% of Modern Applications, New Study Finds” and if you stopped reading there, you might think, hey, it’s not in the apps I work on. Or you might think that because you use OSS software, most of the world also does. Microsoft, Oracle, etc. are headed for disaster.

    If you read a little further, there’s this gem: Open source components are present in 96% of codebases. That’s a far cry from OSS powering most modern applications. I think a better headline might be that OSS helps build most modern software. However, this isn’t an editorial on bad journalism.

    I do think OSS stuff is amazing. Many of us in the Microsoft Data Platform space use sp_whoisactive or the First Responder Kit or Diagnostic Queries or some other OSS in our work. Lots of commercial products are built with OSS libraries or components, or there are free versions. Flyway (from Redgate) has an OSS version. OSS helps us build better software, though commercial packages also help.

    One of the interesting things about OSS is that many very popular projects have just a few people maintaining them. If those 1 or 2 people disappear, then the project might stagnate. Or worse, if there are security issues, no one addresses them. One of the main attractions of OSS is that anyone can provide a fix or enhancement, but the reality is that most people don’t. Most people just use whatever is out there.

    And most people rarely upgrade their OSS. They get something that works and don’t want to change. I get that, as I feel the same way often, especially in the real world. I have shoes, gadgets, tires, etc. that work and I don’t want to change. In the software world, this creates vulnerabilities and security issues, as the report shows with many people still using Python 2. I both understand and don’t understand why this is the case, but I do worry about security.

    The other concern is that few people review changes to OSS packages, which has led to previous supply chain attacks with backdoors or vulnerabilities introduced in packages that many other software developers use. Again, OSS is supposed to be better than closed software at preventing this, but the reality is that most (the vast majority) of us are just too busy to look for issues. Even when vulnerabilities are published, far too few developers see the information. Automated scans in CI/CD systems are great, but again, too few people add these to CI/CD pipelines consistently.

    Software is hard. In some sense, I’m glad databases don’t have external compilers or use anything other than raw code, but plenty of people still write SQL Injection vulnerabilities in their functions and stored procedures, and many don’t have good visibility into the code that is submitted to their databases, often because the code is assembled at runtime. I wish more people just used stored procedures and included more testing and vulnerability scanning, but that’s a dream. For now, I suggest most of you developer patterns your staff can use and stick with them.

    And use version control. At least then we can find all the old, bad code and fix it with some search and replace.

    Steve Jones

  • Distributed Monoliths

    I was watching a video called Microservices are Technical Debt. In it, the person being interviewed said that a lot of people really have a distributed monolith. That caught my eye since I’ve worked with a number of customers who are trying to adopt microservice architectures for their applications. I think this is less a performance/scaling choice than a reworking of their software development teams, and I’m not sure they will end up with a better system.

    What is a distributed monolith? I am not an expert, but this appears to be a place where all the services still depend on each other. For example, I might have a service getting user profile info that an app calls, with another service getting previous orders, and a third service that returns inventory. In a monolith, if any of these are down, the others don’t work. In a distributed monolith, these might be built independently, but perhaps the core app/web page still requires all these to be working to show the user something.

    That’s how my gym app seems to work sometimes. It can’t get my profile and the list of classes and the things I’ve registered for, so it hangs. This is very annoying when all I really need is my ID QR code, which never changes, and is validated by another system.

    In a microservices architecture, if any of these were down, the others would still be working, and the app would continue functioning. If inventory is down, I can still update my profile. If previous orders are working, I can view them even if the current inventory doesn’t work.

    Things are loosely coupled for the end user and for the development teams. Not for just one of those groups.

    I’m not sold on microservices, especially when they include databases. There is a lot of power, and efficiency, from being able to pull together different data sets in a database efficiently rahter than doing so in an application, which might require different API calls, separate db connections, and the delays that come with returning more data than needed to let the client join it together. At the same time, I can see how separate services could potentially scale much higher over time.

    The thing that I tend to see is that most of us never need to really scale as high as the Google/Facebook/Spotify/Netflix/etc. organizations that espouse these microservice architectures. They have different problem domains and different needs than most of us. Even Uber has realized that one size doesn’t fit all and is moving some things from microservices to macro ones. I’m not against microservices, but they need to be used in appropriate situations, not all of them.

    What most of us need is a little more help from Brent or Erik or Paul or someone else in the form of a little consulting that tunes our code to run more efficiently. And if we use them, we should learn a few things from them so that we write better code the next time.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.