Voice of the DBA

Category: Editorial

  • Looking Back at Software Development Trends

    In some ways, the world of software development hasn’t changed much. The same sorts of skills and techniques I saw people using on COBOL programs hitting DB/2 and C++ over Oracle 6 are used today in React and C# against Azure SQL database. On the other hand, it does seem that we are more mature in how we work together and the flexibility with which we design systems.

    I saw the results from a survey from 2019 that Atlassian ran for software developers. This was a look at what modern trends might exist, though over a year later, perhaps the world is dramatically changed again. Let me look at each of the four trends they point out.

    I’ve been hearing about microservices for years, but have found relatively few customers using them. I don’t hear a lot about them in the RDBMS space, and I think this is because the idea of separating out each entity (or small set) in a database and having data access only through a front end component doesn’t make sense. There’s power in using an RDBMS to enforce data integrity rules and allow aggregations. I’ve also seen some companies looking for miniservices, not micro ones.

    Manual testing is still very prevalent for customers. While there are lots of unit tests, including some against a db, they don’t always extend through CI to more complex scenarios. Quite a few customers still have bottlenecks where humans look at the application in a larger sense. I think the high cost of tools that run more complex tests is a part of the problem. I’m not sure how we improve this, though I do hope to see more unit or functional tests for db code.

    Feature flags are extremely complex, though I do see them more as a defensive measure, where features are released, but then turned off if there are issues. This prevents a rollback from the app and db standpoint. I also don’t see a lot of use of dark deploys for database features, perhaps because until the app is working, we aren’t sure the data model is correct. Feature flag cleanup is certainly an issue for some clients.

    The last trend is one I rarely see implemented. Looking at customer outcomes, and not just immediate sales, is something that few people seem to do. Perhaps because developers are evaluated on the work they complete, not whether it’s in use. Managers are evaluated based on getting developers to do work, or on the sales that are produced, but it seems that few organizations try to measure the customer impact. We’ve started doing that at Redgate, and I’m interested to see how this evolves.

    Keeping developers motivated, excited about their jobs, and productive with creative solutions is tough. The trends listed from the article seem to me more aspirational for most of the organizations with which I deal. Most clients I know see developers as interchangeable parts, similar to factory workers. I think if they invested a little more in the well-being of developers, both from their mental focus and the growth of their skills, they might find a lot more benefits accruing from their software.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • What’s the Bus Factor?

    I was on a webinar recently and someone mentioned the bus factor, which is a phrase I’d heard before, but not in a long time. Essentially this is the number of people, or maybe a certain specific group of people, who can get hit by a bus before your organization has serious issues.

    Do you explicitly know who is important in your organization? I’m sure most executives think their personal factor is 1, meaning they can’t disappear without issues. I’m not sure I agree, though certainly we can’t lose all executives at once. In one small company I worked in, we never put more than two execs in a plane or car for a trip out of town, just in case something happened.

    This week, I wonder what your bus factor is in technology. If you think about your projects, your applications and infrastructure, do you know who the critical people are and how many are needed to keep things going? Or could everyone quit and new hires would take over. In other words:

    How many people can get hit by a bus before your org fails?

    I think that in Redgate, we don’t have many people that are irreplaceable. We have four advocates, and while we have different strengths and abilities, we can fill in for each other. Likely our advocate factor is 4. We’d struggle slightly if all four of us left, though I think our sales engineers and some developers could fill in for us.

    In development, we move people around regularly, and while they are valuable and great contributors, I think we could work around a large number of them leaving. I have no idea how many would cripple the company, but it would have to be a number much greater than 10.

    It’s worth recognizing when you have people in critical positions that are hard to replace. Do you have a single COBOL programmer still keeping something going, or maybe just one long time employee that knows how the BizTalk server runs and no one else makes changes. Think about it today, and let us know if you think there are single points of failure in your organization.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Admin Challenges Across Scale and Time

    I’ve never been interested in working on large systems. I know some people relish the challenge, and certainly there is a lot to learn, but I’ve always valued my sleep and time with family. I like getting away from work, seeing my wife and kids, and I’ve found enough after hours work on (relatively) small systems to keep me occupied. To be fair, I’ve often dealt with large in terms of numbers of systems, rather than a large single system. For some reason, managing 200-300 instances that have 50GB databases is much less stressful than a 10TB single instance, at least for me.

    In 1999, I was offered a job managing a 13TB database on SQL Server v6.5. I declined that job, and was glad I did. Running that system would have been a nightmare.  I think a 40TB SQL Server 2017 instance is likely easier to manage, though maybe Taryn Pratt would have taken either challenge. I was interested to see her writeup on migrating a 40TB database recently, though I’m glad I don’t manage this system..

    Even if you don’t have a large multi-TB system, the challenges Taryn faced are similar to ones I’ve had on smaller systems, where I was still space constrained. In some places, a 50GB system might be limited in storage, and you might encounter some of the same issues. You also might have the same moving target problem, where the information you are moving keeps changing and your processes struggle to catch up.

    This is the type of documentation and evaluation that I’d like to see more people produce about their daily (or weekly or yearly) challenges. Having examples of what worked, maybe what didn’t, and the thoughts behind solving problems helps others learn and grow their skills. Even if you only write this for internal co-workers, it’s a good learning experience.

    It’s also good practice for your communication skills, which are going to be very important in the new normal of pandemic work environments.

    I’d love to publish more stories like this, of how you solved the challenges you face as a developer or DBA. If you can write about things, send me a draft. If you need help anonymizing things for your employer, I’m happy to help. If you don’t want to do this publicly, at least consider documenting this type of effort internally. Others might learn, and you’ll have a nice item to present to your boss at review time.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Summer Reading

    I love to read. Ever since I was a kid, I’ve almost always had books nearby. In fact, I used to go to the PASS Summit with 5-6 books in my suitcase, just in case I went on a reading spurt while I was there. I’ve actually finished 4 or 5 books during that trip.

    Every year, I used to love to see Paul Randal’s summary of his reading (2019 here). While I don’t do the data analysis that Paul does, his past posts did inspire me to use GoodReads and track my own reading. Last year, I read 128 books, most of which were fiction. I lean that way, as a way to escape from the chaos of life. So far this year I’m up to 57, though most of that was my sabbatical and the early pandemic times. Now I’m busy and slowing down the reading.

    We’re nearing the end of summer, a time when I’ve usually read less as I’m outdoors more. Perhaps that’s the same for many of you, but it will get cold at some point, and I assume most of you will find free time to enjoy a little reading.

    Today I’m wondering if there are books you recommend for people to read in the technology area. What books have you enjoyed that are based around technology?

    I ran across a post from Frank Denneman, asking about your favorite tech novel. I’ve read a few on his list, and added a couple others to my list. I also listened to Kendra’s podcast on software development, where she mentions the summer book club from IT Revolution where people are reading The Unicorn Project. I do recommend that one and The Phoenix Project.

    Give us a recommendation today if you have one for a novel that you think of when I write “technological thriller.” Fiction or non-fiction.

    I’ll leave two here that I enjoyed. Cryptonmicon from Neil Stephenson. It’s an interesting look at encryption and technology. The other one that comes to mind when I think of technology novels is Ready Player One. Maybe because I grew up in the 80s, but the whole idea of learning, living, and working in a computer reality, while still using computers to do things, was very enjoyable. If you saw the movie, read the book. It’s much better.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.