Voice of the DBA

Category: Editorial

  • How Important is a Conference?

    The PASS Virtual Summit is coming up next month, and Andy has a few thoughts on how to get your employer to send you to the virtual conference. As someone that has been through this many times, Andy has good advice, and his thoughts are the types of things I’ve done in the past at various jobs I’ve had. Having a good reason why was important before I started speaking.

    Once I started speaking, I often made a deal with my boss that I’d cover some parts of the event and they’d cover others. We both made a shared investment in my career, which made sense to me. I often used Andy’s line, which is what I was thinking about today.

    This is important to me.

    That’s a good phrase to use. Usually I do a good amount of self learning, I ask lots of questions, scan message boards, and I teach myself various things. However, a conference is a chance to help me think. I get to consider new technologies, I get to talk with others about how they solve problems, or more often, what problems new technologies can cause me. I get the chance to grow in a wider way than I can in the office.

    That’s important to me, and it’s been valuable to my employers. I think that’s the case for some conference attendees, but I do think that some drive and desire are important if you get more out of a conference than a couple days off. Let your boss know you have that drive, and show it off. Remind them of the things you do to invest in yourself.

    Can you put into words why a conference is important to you? Why it’s valuable for you personally, what you get, and does the chance to go to an event make you more likely to value your current position? If so, then maybe ask to go. There are some valuable packages to help you learn. If not, that’s fine, but maybe ask yourself why not. What don’t you get out of the Summit, or any other conference.

    Maybe the main thing to think about today is what is important to you when it comes to benefits and requests of your employer?

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • The API Battle

    I think Oracle is a fine database platform, maybe too expensive, but it works. However, I’m not a fan of the company, and I find myself less enamored with them when I read about this case. This the Oracle v Google case, where Google is accused of violating copyright of Java APIs when it build Android.

    Essentially Oracle claims that the Java API, the packages, classes, methods, etc. are copyrighted and cannot be used in any other product. I assume this means that if I implemented the Java.SQL class, writing the code in C#, I’d be infringing on Oracle’s work.

    Even if I offered my software for free, this could be legal violation and I’d owe Oracle money. Or I’d need to license the API from Oracle. Any guesses on whether that would be inexpensive or prohibitive?

    In one sense, I do think that copyright and patent protection should exist. On the other hand, I think some of the applications of the original laws and ideas to the digital world don’t translate well. I certainly think that APIs shouldn’t be protected. These are essentially function names, and while I appreciate the need to copyright words, I don’t think it should go this far.

    I am hopeful that the Supreme Court will hear this case, and rule that this isn’t a violation. As someone that works for a software company, and has written software designed to inter-operate with other products, I think this would cause lots of chaos in our industry. I also think we have enough silly licensing and limiting practices in software, and I’d prefer to see less, not more.

    Steve Jones

  • What’s the Lunch Factor?

    A few weeks ago I wrote about the bus factor. This is the number of people that could cripple your organization if they got hit by a bus. Maybe a better way of looking at this is the lottery factor. If these people won a lottery and quit, would they cause problems? There were some interesting answers in the discussion.

    There is another factor that I heard about in a presentation that I found interesting: the Lunch Factor. This is the number of people that have to get involved for you to deploy changes to production. Today, I wonder what your lunch factor is? Leave a note in the discussion.

    This may be one set of people in your organization for things like patches, which are supposedly tested and approved by the various vendors you use. For software that you develop internally, likely there is a slightly different group of people, with some overlap. Usually the Operations staff is the same in both situations.

    In a true DevOps organization, the idea is that developers can actually release code to production. Maybe not every developer, or not every developer can release every type of change, but the idea is that developers can, and do, release code. They’re also responsible for this code. In my discussion with Donovan Brown and Abel Wang of Microsoft recently, this is how they view the world.

    They also would likely have most code released triggered and controlled by feature flags, which might ensure that customers can’t see the code right away, or that the code doesn’t break existing customer work. This also ensures that you can turn the feature off if there are problems. I’m a big fan of feature flags (or feature toggles) and think they are way too underutilized by many organizations.

    Allowing developers to release code is difficult for many managers, and even for Operations staff. There is always the worry that developers don’t have the expertise or accountability to make these decisions, and many orgs don’t have the capability built in to allow this, much less give the authority to a wide group of people.

    Microsoft does, as do lots of organizations trying to embrace DevOps and produce higher quality, more adaptable software. Many of these companies are bound by Sarbannes-Oxley and other regulatory rules, and they make it work. They grow, change, adapt, and most importantly, constantly improve their systems and process to allow this. For them, the lunch factor is 1, or maybe 0 if you consider that no one needs to get taken to lunch. What’s your factor? What staff, managers, even change control boards have to get involved? Let us know today and then think if you could reduce that number.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.

  • Pulling Together

    When the COVID-19 Pandemic grew rapidly in early 2020, medical supplies were in short supply. Different areas and organizations struggled with different types of issues, and one of the higher profile issues was with ventilators. In March, the projections were dire and quite a few hospitals were worried about the supplies of these devices. This was especially disconcerting given how many people were being placed on them and how long it takes to produce them.

    I met someone at that time that said getting a car company to produce these wasn’t possible. The factories were specialized and converting machinery and people wasn’t something that could be done in months. This was someone that claimed to have over 30 years of manufacturing experience.

    I had no basis to argue, though my instinct was that we have mobilized large industrial efforts in the past. When I read this article recently, it made me think about that conversation. Microsoft worked with a number of manufacturers to produce ventilators quickly, up to 400 a day in the UK. The story is interesting, and it shows that engineers at companies like Ford, McLaren, Unilever, Rolls-Royce, and more can not only work together, but also focus their efforts in a crisis. With the help of technology and data, they transformed a manufacturing process from the ground up to meet the needs of the UK.

    If you watch the video of the effort, it is amazing to see just how knowledge and data are brought together to ensure these devices can be built quickly, and at a very high level of quality. Certainly some PR is involved here, but the keys to success in producing something are the knowledge and skills being applied to a task. Products like dashboards and the Hololens help to move knowledge around where it is needed. In building software, tools like Live Share help to move knowledge from one person to another.

    The coordination of people working together, driving to a common goal, is critical as well. DevOps asks us to practice this, choosing to be a team, with the goal of increasing quality while we focus on delivering software to customers. This is a great story, but one that highlights things that many of us could strive for in our daily work.

    Steve Jones

    Listen to the podcast at Libsyn, Stitcher or iTunes.