Voice of the DBA

Category: Editorial

  • A Clock With Benefits

    One of the difficulties I think that developers face is that so few people understand what actually goes into producing software. The end result that a user sees can mask the effort and complexity of the underlying code. A person might see one application that required months of effort and not understand how it’s different than a similar (in their view) application that was prototyped and completed in a week.

    I’ve seen a few efforts to try and explain how code is written, and I think the huge piece by Business Week was a really good explanation for the layman. It tries to simplify concepts, and does so in a humorous way. I suspect that this piece might actually help our clients and customers gain some appreciation for the difficulty of producing a basic application.

    However I think we need some additional articles like this to help explain our database world. While there are some good, basic pieces on what a database is, we don’t necessarily help anyone understand the complexity of assembling disparate data, especially at scale.

    I don’t think end users would care much about why database performance can be an issue, but I do think that some well written, easy to read, enjoyable pieces on the issues of writing poor database code might give developers some appreciation for why indexes matter, what RBAR does to performance, and what solutions might help their code shine.

    No one wants software written poorly, and no one wants deadlines missed. However the world of software development is complex and the more that we can help our clients understand this, the less time we waste on explanations.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.3MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Surfing

    How many of you have gotten up before dawn, driven to the coast, gotten on a long piece of fiberglass and paddled into the ocean before turning around to ride back to shore? It’s a great way to start your day, and I’ve been lucky enough to do this many times in my life. I look forward to getting back out there someday in the future.

    Surfing is an interesting sport, because you don’t really get to pick your path. You catch a wave, and begin riding it in, altering your course based on the speed of the water, the height and structure of the wave, and even the way the current is flowing. While you move in the direction you want, your choices are limited.

    This is unlike many other moving sports. While snowboarding you can stop or slow down. In many wheeled activities you can go in almost any direction. Much of the time you have more control over your motion, and can even take a break.

    However waves are unique. They’re few and far between. If you want to slow down, you end up really abandoning that journey, one you’ll never get again. If you paddle back, you’re hoping you’ll get the chance for another fun ride that day. That isn’t always the case.

    I saw someone post a note that working in technology is like surfing waves. As we learn and grow, we often feel that we can’t slow down, or change directions very much. If we’re a SQL Server DBA, we’re riding that wave. Trying to slow our career, or move to another technology means (often) abandoning some of what has worked well for us. We really follow the wave we’ve chosen as often as possible, usually resistant to change.

    You can change, however, and if you want to do so, make some plans and look for a new wave. It will take time; it will require some investment, but it’s possible. Always remember life is short, and we want to work in order to enjoy our lives with friends and family. We don’t want to get stuck working in ways that prevent us from enjoying our lives.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 2.5MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • Why Use Version Control?

    I’ve spoken with quite a few people in the last few years that don’t see enough value in version control to actually implement it. Most of them agree using a VCS is a good idea, but they aren’t doing it. Maybe this analogy will help.

    I was listening to Ike Ellis talk about VCS and he said something like this. Imagine you had a ten foot board to walk across and it was laying on the ground. You’d be willing to walk, skip, dance, maybe cartwheel across it. After all, what are the consequences?

    Now imagine this board is 50 feet off the ground. How do you cross it now? Many of us would be more cautious. In fact, if you’re like me, you’re likely laying down on the board, gripping tightly as you move inch by inch.

    However, what if there were a net below you? And if you fell, this net would toss you right back onto the board where you’d fallen so you could continue on from the last place you’d had success.

    That safety net is your VCS, and when you’re working along coding, you’re crossing a board that’s quite a distance from the ground.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( MB) podcast or subscribe to the feed at iTunes and LibSyn.

  • The Road to Success

    I heard this quote recently from Dan Wood of Northwest Cadence. “The road to success is paved with cobblestones.” The meaning is that as we get better and gain success in those things we attempt, it will be a bumpy road. If you’ve ever driven (or walked) down a cobblestone road, you know what I mean. It’s not a path you’d want to take every day in a wheeled vehicle.

    In other words, we will make mistakes.

    In talking and teaching about software development practices, I think far too many people, myself included, become too concerned about mistakes. We worry about our code being perfect, or we struggle to implement newer features because we lack the confidence to try something new.

    This is one of the reasons I think moving to a well engineered software delivery pipeline is important. The ability to make changes to code quickly, run tests, and deploy smoothly is important. We will make mistakes in our programming. We will have bugs. Even as we improve our ability to write better code, we will make mistakes that we want to fix quickly. Having a smooth process that allows us to deploy new changes, as well as prevent old ones from re-occurring, will separate the great development groups from the average ones.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 1.7MB) podcast or subscribe to the feed at iTunes and LibSyn.