Voice of the DBA

Category: Editorial

  • An Experimental Mindset

    I wrote a post about Git recently since I’ve found far too many people who didn’t know Git well (or at all) and they seemed hesitant to experiment and learn.

    Is this because of being too busy? Do we have so many people who are working in tech where “it’s just a job” and not because they enjoy technology? Or has management in too many places beaten people down to the point they don’t want to try things? Perhaps your coworkers are resistant to change (or lazy) and you don’t want to discuss new ideas with them.

    In working with software and databases, I marvel at all the ways in which we can mold and change the system to match the creative ideas we come up with. I’m pleasantly surprised when someone solves the same problem I do, but in a very different way. Even using the same language/tools/frameworks, we can often come up with a variety of solutions that work well. I think we teach each other something when we compare disparate solutions.

    When I was learning about computers, we were encouraged to experiment. Those who were willing to try things and learn from them were often more excited by the task, and I think these were often those who went on to successful careers. I’ve found the people who don’t like to experiment or try something new, even when there is no risk, are often limited in both their accomplishments and opportunities.

    I don’t expect those who enjoy experimenting with technology to work more than others. I’d prefer that everyone have a balanced life that separates time at work from personal time, and limits the investment in your skills to a reasonable level. Live and enjoy your life outside of technology, but when you do work, make an effort to do your best work, while working to improve what “best” is for you.

    Try something new this week. Solve a problem, use a new tool, read about new technology, and write a little code. It’s good for you.

    Steve Jones

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

  • Re-platforming

    Re-platforming is the process of moving a system to a new platform. Imagine taking an ASP.NET/SQL Server website and moving to Azure Functions on Azure SQL Database. Or maybe taking a Java client/server app with Oracle and moving it to a series of microservices against MongoDB. Those changes could be a net benefit to your organization in the end, but they aren’t quick or easy. They’re often fraught with various challenges that can cause a lot of stress while creeping over budget.

    There’s a post that talks about some of the things you might think about if you embark upon a re-platform. Often this takes place when an organization is looking to modernize their tech stack. Quite a few of the technology DevOps success stories take place when the older structures are not maintainable, but also not able to handle increased workloads or performance requirements.

    It’s often said that a complete rewrite rarely makes sense. I think that’s likely true, but that doesn’t mean it isn’t something you should do. It says that you should rarely do it, and you need to pick a good time when your old application, database, network, or some combination of these can no longer meet your anticipated future growth demands. This is likely a debate that your organization should have every year or two and ensure that continued investment in the current platform makes more sense than a new one.

    Once you decide to move forward, it will be a journey, which means understanding how new and old systems will interact becomes important. Compatibility, at least for some time, is very important. I’d say this is especially critical for how your data systems will work together and what options you have to replicate/ETL/etc. the data between systems.

    Even if you plan to make a cutover from one system to another, data migration is fraught with issues. Anyone trying to ensure data moves cleanly from one place to the next should have strong checks, usually with automated tests, that evaluate if your data is moving correctly. Row counts aren’t enough, or not the only metric. Random checks of individual rows, as well as checks for outliers, should be a regular part of any project that will migrate data. Learn where you struggle to correctly transform data because there will be places where this happens.

    I don’t believe that wholesale re-platforming often makes sense. Leaving SQL Server to go to another database platform, or even when you might try to change the paradigm with NoSQL or a Data Lakehouse, often costs a lot. Getting a return after staff training, migration costs, and even delays from inefficiencies during the process often equals many years of licensing. I think slow migrations are a better idea, perhaps adding something like ElasticSearch or Redis, experimenting with a small data lakehouse for a particular purpose, and replicating some data to Neo4J for complex hierarchy queries. These evolving mechanisms give you the chance to experiment and learn about the process. It will help you understand if there is a positive ROI if you continue.

    In many ways the world of technology changes slowly. We have lots of new shiny toys, but many of them don’t magically solve your problems. There are always tradeoffs and without strong domain knowledge, you may have more unknown unknowns that reduce your chances of success. Re-platforming can work, but make the decision carefully and proceed methodically, not with haste.

    Steve Jones

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

  • Protecting Off Hours

    Legislation was introduced in Australia to allow employees to protect themselves from unreasonable calls and emails from work during off-hours. You can read more about it, but a bill was passed to allow employees to ignore calls and messages without repercussion  It is expected to pass, though I don’t expect this to do a lot for bad bosses. They’ll find ways to hint or imply that you need to respond, and might even remove your chances of advancement/promotion/raises. While you can sue, that rarely works out well for anyone.

    From the various reports I’ve seen, I’m not sure if this includes salaried workers or just hourly workers. I certainly think hourly workers ought to be paid if they’re called after hours. I’ve even been paid as a salaried worker if the calls outside of core hours exceeded a certain amount per week. That seemed fair to me, and in our team, there was always someone willing to work more for extra money, so I could trade on-call work if I didn’t want to do it.

    As a side note, my second time on call (for a week), I got paged over 40 times. It was a nice paycheck, but not worth it. I had toddlers in the house, and I slept with a vibrating pager on my chest to not wake my wife. It was not a good week and I traded away my on-call weeks to others, sometimes even sweetening the deal by buying them lunch.

    There are a lot of people working in technology who don’t like the job and don’t recommend a career in this business precisely because they are overworked. The US has a very poor work-life balance in general, and many people feel pressured to work lots of extra hours. My colleagues and friends overseas do lots of work, and seem just as productive, but don’t arrive early, leave late, or work weekends very often. Sometimes they do, but not often. In the US, many people work more than 40 hours regularly, with a commute, and think this is normal.

    There are times when extra work might be needed. However, with plenty of us working from home after the pandemic, it’s important to strike a balance of some sort and learn to get away from work. I’ve worked hard to reduce my hours from a regular 60 while owning and running SQL Server Central to something more reasonable now. I certainly have weeks I work more than 40, but I have weeks I work less.

    Balancing the workload in a day is something else I watch. I try hard to not set meetings or work too early or late, but the nature of my job means I work with people in the US, the EU, and Australia. As I write this, I started work at 8 am this morning with a meeting and I have an 8-9 pm webinar for the Australian region. However, I went to the gym at lunch and coached kids for a few hours in the late afternoon. I found a balance and while I might have worked 9 hours today, I don’t often do that. I will take 6 am calls, but not regularly.

    There is something satisfying about working hard to earn your paycheck each day. It gives one purpose and satisfaction for a job well done. At the same time, it’s important to get away from work, enjoy your family, friends, hobbies, faith, and more. In technology, where regular hours aren’t always part of the job, you must manage your life well. I don’t know that legislation would help in the US, but I am interested to see how this proceeds in Australia.

    Steve Jones

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

  • Growing Skills at Work

    Redgate released the results of their State of Database Landscape recently, and I was part of a webinar where Beca Parker, Ryan Booz, and I discussed the results. As we were talking, one of the things that struck me was the high number of people who had picked skills as being a challenge for their organization. In a single environment, skillset requirements and training were the number one challenge, and it was listed as the number one obstacle to implementing a DevOps approach.

    While this industry is full of self-taught individuals who have spent time learning new technologies and tools, it’s somewhat amazing that training continues to be an issue. Many organizations limit their training budgets and time allocated to employees while continuing to expand the number of technologies and platforms they use. This is one reason why I think changing database platforms to avoid licensing costs is unlikely to save you money anytime soon. Retraining staff and developing competence takes time. Perhaps this is also one reason why many companies look to the cloud, thinking that they can reduce the amount of upskilling needed by their staff if the cloud vendor manages the systems.

    That might be true, but there is a lot of knowledge is still needed about how the underlying technologies work, especially if employees are to efficiently write code or make configuration changes in the system. The cloud can be more cost-effective, but it can easily be less cost-effective. Knowledgeable employees can make a difference.

    I do see plenty of organizations subscribe to online learning, but often I find these courses good for basics, but not necessarily helpful for specific situations and just-in-time knowledge requirements for projects. There more custom training, or at least, group support, is needed to ensure that your staff is learning efficiently. Far too many people can’t handle open-ended training from an online platform and complete more than one course.

    Training isn’t enough, as there also needs to be some practical application of new skills in your environment. Practicing katas as a group, coaching each other, and applying skills to actual projects while measuring results is important. It takes some commitment from both employees and organizations to get better. Far too often, I also see staff unmotivated to learn and grow, for a variety of reasons, but that’s a different problem that we have to work to solve together.

    The world of technology in business is growing increasingly complex. We find more and more organizations adding technologies, especially new database platforms, and we lack skilled people to work with them. That’s a constant challenge, but one that creates opportunities for you if you find ways to improve yourself.

    Steve Jones

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