Voice of the DBA

Category: Editorial

  • Databases for Executives

    There’s an article at Forbes about the Five Things Business Leaders Should Know about Databases. Disclosure, it’s by my boss, but I think it’s still a good read. These are points we’ve learned from research and work with customers and prospects at Redgate Software. These points come from you, as well as from executives with whom we work, but there are so many people in organizations who don’t think about the complexity of data, so it’s a good one to pass along.

    The five things are (if you don’t want to read): data is growing, getting more complex, there are multiple database platforms in most estates, teams struggle (duh), and data is a business issue. Most of us know about the fourth one, often because we may feel overloaded with work. We might also feel a lot of stress in trying to keep up with not only the workload but also trying to learn more to support the ever-growing variety of systems it seems our employer wants to put into production. I regularly talk with customers whose developers keep wanting to try out a new, shiny database platform in the cloud (or add new features from their existing platforms).

    Wait, not try out. They’ve already deployed some production data there and now want other developers or operations people to work with their system.  Often lots of the staff isn’t familiar with the platform or feature, even the people who decided to implement it. Is anyone familiar with that situation?

    The digital transformation and importance of software isn’t lost on most executives, but I find far too many that don’t place the same importance on the data that powers their software or the database platforms that support all software. Data is important, and ensuring it is available to software, protected, secured, and available is critical. That also means that the process of developing and managing the database portion of your software matters.

    I think Database DevOps is important, but it’s not a panacea to buy a product. I’d love to show you what Redgate Software can do here, but the main thing I stress to clients is that you need to get your database development into the modern era and match what software developers do. That means a smooth process, with version control, that ensures you deploy changes in a way that doesn’t impact customers.

    This doesn’t mean just go faster. This means bringing along data modeling, good architecture, and performance testing. Those are the same things we’ve been doing (or should have been doing) for decades, but we need to ensure these are still a part of whatever process we choose and included in any automation we implement.

    Pass the article along to your management, and be sure they understand that all these points are important. Particularly the fourth point because if your staff isn’t supported and trained, the rest of the business will suffer.

    Steve Jones

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

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

  • Knowing Your Total Reward

    For much of my career as a younger person, I was mostly concerned with salary at a job, along with the opportunities for my career. I really wanted to know how much money would hit my bank account and cared most about that. I also wanted to know if I would learn something or get a better title or work with a technology that might help me in the future. That drove me through quite a few jobs in my 20s and 30s, leaving some for more money and more opportunity.

    As I got a family, I became more concerned about healthcare since that industry is a mess in the US. Often when I looked at a job, I perused other benefits but didn’t give them much weight, mostly concerned with salary and the cost of medical insurance. I also somewhat cared about who I worked with (the team), but that was more for helping me choose between different jobs. It wasn’t something I thought of as a reward, though I should have.

    Recently one of our internal recruiters shared a post on LinkedIn talking about total reward. This was from an HR company, but I really liked the idea of total reward. There’s not a lot to the post, but it noted that many HR and management think total rewards for employees are salary + benefits. It highlights that there is more, which includes all compensation (competitive + performance-based), work-life integration, career opportunities, supportive culture, and human-centric policies. There’s a graphic that highlights this idea.

    Early in the SQL Server Central days, Andy and I were talking about his job search and how he viewed the entire package. He cared about other things, often looking at certification or education compensation, time off, commute, and more. Some of those things were important to me, but they often were nice-to-haves next to the salary. The total compensation made more sense for him to evaluate, as employers sometimes have very different policies. He tried to put a monetary value on each benefit to compare them. He had one company that paid him for each certification he got, which added up to quite a bit of money on top of his salary when he got certified in most of the Office products.

    Today I’m wondering if some of you think about your total reward from employment. Do you weigh in the different types of benefits you get? Can you put some value on a particular policy your employer offers? As an example, I made this choice years ago when a company in Denver offered me a fair salary and position. However, they were unwilling to let me work at home more than one day a week. At the time I had young children and I would lose 90 minutes every day to a commute. I countered with $15k less salary each year and 3 days of work at home. They declined and we went our separate ways. I was very happy with that decision, as my time had real value to me.

    These days I think about the total compensation I get, with a lot of flexibility and autonomy, on top of interesting work and good compensation. I also think about stability and security, which are important to me since I really, really don’t ever want to have to look for another job.

    We should work to live our lives, and understand that while work is important and provides purpose, it’s a part of our life. We spend a lot of time in our jobs, so we should ensure our total rewards are a fair trade for our time.

    Steve Jones

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

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

  • When Companies Fail

    I own a Tesla, which is essentially a computer on wheels. Much of the way the car works is driven by software, which I love. New features have appeared and minor fixes come through in the same way that they do for apps on my mobile device. It can be annoying to wait for an update to install, which has happened when my wife or I start the update remotely and don’t realize the other is planning on driving. Fortunately, I can set these to run overnight from my phone and they mostly disappear into the background.

    I don’t worry about Tesla failing, at least, that hasn’t been on my mind, but I ran into this article about a company in China that is failing. The WM Motor Company filed for bankruptcy, and perhaps coincidently, their app stopped working. Owners couldn’t manage basic functions. The company put the server back up, but that brings up a bit of a concern for software that depends on external connections.

    This raises concerns for Fisker in the US, and really, for any sort of device that one might buy that could depend on an Internet connection for operation. It’s one thing to have updates and options, it’s another for a device to just stop working because the company is gone.

    Consumers don’t have a lot of power with regard to software companies, but we do have some. As software becomes more prevalent and important in other parts of our lives, I would advocate for some sort of open-sourcing of software in live devices if companies fail, or even if they decide to discontinue support. I have a 23-year-old car that works fine, and I can get parts. Dealers don’t want to work on it, and it has been a challenge at times to find OEM parts, but there are plenty of third parties.

    We ought to have third parties in software as well.

    Most of you work for a company, which often makes its own software. If your company abandons a piece of software, everyone adapts and moves on. Even if your company sells a service, it makes sense they could discontinue the service. However, when you sell a physical product or even a physical install of software, I think you ought to give customers a way to maintain their system if you decide to stop doing so.

    Update: another issue with Fisker (SMH)

    Steve Jones

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

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

  • Tech Debt Perils

    My wife and I have been thinking about some new audio equipment. We’ve been a little unhappy with our Bose soundbar because of the software flakiness and sporadic network connectivity issues. In looking around, I saw a Sonos product, but after reading a bit about the company’s recent history, I decided to look elsewhere.

    Sidebar: if any of you have recommendations that aren’t high-end $$$$ audio, let me know.

    I saw this article about some of the problems Sonos has had, and it resonated with me. I’ve been in a place where I’ve worked on software that had a lot of technical debt and needed to be changed/improved to help grow the company. Management was pressing everyone to get the software ready quickly, without more concerns about the customer experience or the quality.

    That seems to be what happened with Sonos, where they released new products and new software, with the software missing functionality that their customers needed. There were bug reports, bad press, lower sales, and canceled raises/bonuses. Those last ones, to me, ought to be completely focused on executives and managers, but I’m sure that’s not the case. Management rarely takes the blame, but ultimately they are responsible for hiring, training, steering the employees, and deciding to launch.

    The story reads like a summary of The Phoenix Project. Technical debt, poor project management, and pressure to increase sales combine to create a disastrous launch. It’s always hard to know where to assign blame, but clearly, good software engineering wasn’t a priority, nor was reducing technical debt. I know it can be hard to balance the need to alter software with the need to keep it maintainable, but in this case, they made poor decisions.

    The article says there were yelling and screaming in meetings, and concerns from developers about pushing back on senior leadership on the timelines and demands. Some of us might have been in those situations, and my experience has been if there is management that doesn’t value software engineering, any particular developer is vulnerable to a layoff or termination if they complain. If management doesn’t value software, they don’t value developers and think they can be easily replaced. I’ve seen quite a few companies start to fall quickly with this attitude when developers are not valued. I also see constant job openings and employees constantly looking for other opportunities at these organizations. People only stay long enough to find another job.

    Software is complex. It’s going to have some bugs. There are always tough decisions about which things to work on now and which to delay. I hear those conversations, and I find myself trying to balance the needs of sales and engineering. We need both, and we also need to ensure we can change directions in the future. Paying down technical debt should be a regular occurrence to ensure the software is maintainable and adaptable. I know that when we look to quickly take advantage of new opportunities, this can mean we’re adding new technical debt. Walking that line is the key to success.

    Steve Jones

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

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