Voice of the DBA

Tag: DevOps

  • A Computer on Wheels

    I enjoy cars, and I’ve owned a lot in my life. In fact, I resurrected my list and I count 30 for my wife and I, with 1 motorcycle, 2 ATVs, 2 UTVs, and a tractor. Likely a new tractor or skid steer coming in the next few years as this one is 14 years old. I was hoping for a different car this year, but with two kids needing help, I’m going to have to delay my gratification for another year or so.

    For years, Glenn Berry has been trying to get me to look at a Tesla. He’s owned a few and has driven me around. I’ve never been thrilled with them from a design perspective, though they are quick. Recently I ran across this video (5 Features that didn’t exist when I purchased my Tesla model 3), and for some reason I watched it. It caught my eye (especially dog mode) in that Tesla is doing DevOps with their cars, introducing new features in a way that evolves the car into something new.

    Since then I’ve watched a few other videos, and the Model Y is intriguing. It’s got more range than the cars originally did and it’s not a crazy price. It’s expensive, and more than I want to spend, but it’s tempting because it’s a computer.

    The way that DevOps is changing software is moving beyond tech companies. As I study more about how some companies are building better software quicker, I see that this is finding its way into more and more types of industries. From finance to medicine to manufacturing to shipping to anything, there is tremendous investment in software developers and computing technology to transform industries.

    More and more we are going to depend on software, which means that quality, security, and more are going to become more important. They already are becoming issues, as different companies are realizing just how costly it can be to remediate software bugs for their customers.

    I don’t know if I’ll get a Tesla, but it’s on my mind. If I do, I’ll ping Glenn for a referral code, and then likely be reminded forever that he introduced me to the car.

    Steve Jones

    Update: My wife and I went to test drive a Y. She loved it and actually decided to sell her current, 1yr old car and use that money for a Model Y. So I’m getting a Tesla. Or half of one.

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

  • Tesla and DevOps

    That’s how someone described a Tesla recently, talking about how the software keeps changing. I had watched a few videos after I stumbled on this one:

    That got me thinking, and writing. I’ve got an editorial on this coming up, but really I was intrigued by the idea that the car would be upgraded, and not by unlocking features, but by adding them.

    I wrote before about BMW adding lots of things to the car and letting you unlock them. You could rent heated seats, for example, for a road trip, or a few months. Or rent them in your newly purchased secondhand car, when the previous owner never wanted them. That’s an interesting idea, but it’s simple. We know what’s available, and we pick from the menu of features.

    The Tesla thing is more interesting. They are upgrading the car. They have upgraded software to add more range to vehicles. They added sentry mode and dog mode. The change things, which sometimes is annoying for users when the UI moves, but it’s a neat idea.

    It’s DevOps in real time and in the real world. Not everything works, but not all changes in cars work. Plenty of mechanical designs find flaws and the last few decades, plenty of car software has had issues. I wish that more companies would adopt the upgradeable car, and make changes to improve things. Simple things, like letting me roll up windows remotely. My BMW had remote locking doors from an app, which I used when I got the airport, went inside and wasn’t sure I’d locked the car, but they stopped some of those features and turned off the wireless update (likely a security issue).

    I’m becoming more intrigued by Tesla, and I am considering one for the next car. I wouldn’t have thought that a few years ago, but for some reason the fans are convincing me.

     

  • DevOps in Space

    Some of the early science fiction books I read were by Robert Heinlein, often including rocket ships and space travel. These days I’m uninterested in actually going to space, but I am excited by the prospect of the efforts being made to send others. It’s an exciting time to be interested in travel off of this planet.

    One of the headline makers is SpaceX, which has had quite a bit of success launching reusable rockets carrying all sorts of cargo. My son was very interested in their work as an 18 year old, and I still remember taking him to Cape Canaveral and watching the first first rocket launch and land at the facility. An exciting time for us.

    SpaceX has adopted a DevOps attitude towards their physical rockets, adapting and iterating quickly to improve their designs. The pace of progress is quite interesting, analogous to how some companies have changed their software development lifecycle practices, becoming quite adept at building and improving applications in a rapid fashion. Alex Yates draws some parallels, and includes lots of fascinating rocket information, in this post on the Octopus Deploy blog.

    One of the big challenges I find with changing software development is that we struggle to let go of old practices. Even as we look to iterate, often we are unable to accept risk, and we often want to stick with the “always done it this way” for some things. While we might accept some changes, we don’t accept others, and may even cancel out the benefits of automation improvements with a lack of willingness to adapt our culture.

    I do hope that other companies challenge SpaceX, and learn from them. Ultimately we do better with a competitor that forces them to continue to improve and not rest on past success. The same is necessary for software development teams to continually improve. If your organization is stuck in a rut with software development, request (or push) for a team to try something new. To adopt and grow with DevOps. Make them prove they can build, deploy, and operate software in a better way. Then challenge other teams to try and adopt their ideas, and then improve upon them over time.

    Steve Jones

  • My Time is Valuable

    In most of my jobs, I’ve been given tasks to accomplish, often without a lot of my own input. Someone triages work, or develops a project plan and then assigns me things to do. Often these are fairly narrow pieces of work, but with some latitude on how I might actually complete the task.

    Over the years, I’ve been asked to do things that weren’t a part of my job. At one small company, I spent an afternoon making Ethernet patch cables because we needed them, I knew how, and my boss said it was a good break for the two of us. At another job, I was asked to help go through the separation process when employees left, zipping up files, archiving mailboxes, etc.

    At the same time, I recognize that for my salary, neither of those were a good use of my time. At least not from an ROI perspective for the company. Those are simpler, low value tasks, and for someone that is paid above a beginning level, these were expensive resource costs.

    As we look to improve how software is built *and* managed, we want to take away low value tasks that don’t require human intervention. We want to use computers to do as much of those tasks as we can. That’s a lot of what DevOps tries to get us to adopt as part of our daily work.

    However, this can even include tasks where we might think a human is needed. I heard someone say recently that they shouldn’t be spending time with auditors walking through logs or looking up process documentation. That stuff ought to be produced and available automatically or in a a self-service way.

    Improving the efficiency of our workforce should mean that we don’t spent time doing simple things that can be handled by computers. Sometimes it’s not easy to decide if the automation or tooling is necessary, but at each point we ought to consider the cost of building and maintaining some solution over the cost of an individual spending time there. Often, though not always, we can find a little software development saves a lot of future costs.

    Steve Jones

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