Voice of the DBA

Tag: software development

  • 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.

  • Mission Critical Deployments

    Talk about a lot of pressure to get a software deployment correct. A software install on an Airbus airplane resulted in a file containing parameters being wiped. This error caused (apparently) an airplane to crash when three engines cut off in flight and four people were killed.

    I don’t know if this is the final report on this, but the fact this is a possibility concerns me as a technologist. Certainly we have probably had similar mechanical failures and installation issues in the past, but there are some scary issues here with regards to software. There was a faulty software installation (yikes!), a poor architecture (not assuming more then 2 engines would stop), too much tolerance for software errors (the review letting this pass), and poor overall design (no alerts on the ground).

    I can’t decide if I think that software makes issues like this more or less likely. Certainly checks of physical systems are skipped regularly by people. It’s far easier, and more reliable, to automate checks of software systems, especially with deployments, than it might be for complex mechanical changes. However, maybe that’s not true. Perhaps mechanics are more likely to notice a loose bolt than a misconfigured software menu. Or maybe we need a new type of mechanic that’s savvy with technology.

    Ultimately I think that any software that makes changes to systems, including through deployments, needs to have double checks by an independent process and clear alerting of any issue, not relying on someone to look for the success of a long series of steps. We also need to take review of potential software errors very seriously and ensure the tolerance for potential issues shrinks as the impact of those issues rises.

    Steve Jones

    The Voice of the DBA Podcast

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

  • How many environments?

    One of the things I’ve learned over time is that in order to develop software, you need multiple environments. I think that outside of school projects, I’ve always used at least two environments: development and production. At school there were times I worked on software that I also used, and would make changes on my live (and only) system. I had no shortage of regrets, and whenever I question using a Version Control System (VCS) or separate environments, I think back to those days.

    People I meet these days that develop software almost always have more than one environment, and most have at least 3. The most common model might be development, test, and production, but plenty of people work with even more. Maybe not as many as the seven Grant once had to deal with, but I have worked in environments where we had six database environments for one of our software pipelines.

    How many different environments do you work with?

    The poll this week asks for the count in your organization. I realize that you probably have multiple applications and test environments, but choose one or more and give us some answers.

    The most I’ve worked with was in a financial services company. We had a development database and a separate QA system for testing. There was a staging system to mimic production, a Beta database for users to actually test against and production. That worked well, and we were able to easily refresh environments as needed without impacting our development efforts. Mostly because we have a strong DevOps type process.

    Let us know this week how you’ve got your systems set up and what each one is used for in your software pipeline.

    Steve Jones

    The Voice of the DBA Podcast

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