Voice of the DBA

Category: Editorial

  • When Work Isn’t Done

    Software development can be a challenge for each of us with lots of demands and the need to ensure your code solves a problem correctly, efficiently, and completely. Juggling the workload by yourself is one thing, but add in a team of developers, and the complexity quickly grows.

    The real world is chaotic and despite the best efforts of project managers and scrum masters, our software development life cycle doesn’t always proceed smoothly. I wonder how many of you run into this situation and how you deal with it.

    Developer 1 gets a piece of work, let’s call this A. They complete this and send it to the QA team. Somewhere during this process, Developer 2 get’s a different piece of work (B) and writes code. They send this to QA before A is completely tested.

    Now, Developer 1 finds a mistake. Something doesn’t work or they realize their solution is incomplete. QA is A + B, but A doesn’t work and needs revision. B passes testing and needs to be deployed. If your codebase and QA have both A and B in them, how do you strip out A or B and ensure B is deployed to production but A isn’t?

    If this is C# or Java, you might have one solution, even if both changes are in the same class. If this is database code, you might have a different set of issues to deal with.

    Really, the question is can you reorder work in your deployment process? I find many customers don’t consider this when they are evaluating their software pipeline. They somehow assume if code gets to QA that it’s good, which is nicely optimistic but not realistic. At some point, we’ll deploy code to QA that doesn’t work. The more developers we have, the more likely this is, and the more demands on our time, the more likely we need to reorder work and release one thing but not another.

    As a DB developer and DBA in a company 20 years ago, I built a process and forced us to reset the QA environment and redeploy B only (using a branch of code that stripped out A) for re-testing. This ensured that we tested what was going to be deployed. However, I find a lot of organizations can’t do this or don’t want to. They want to hope that a human and either extract all of B or strip out all of A and release partially tested code without issues.

    I find that to be a poor idea. In this era of regular staff changes, staff of varying quality, and the high complexity of software, this is asking for mistakes. With cheap hardware, virtualization, and the ability to provision copies of environments, we ought to do better.

    How do you handle this today? Depend on humans to not make mistakes? Hope for the best? Or follow a repeatable, reliable process that accounts for inexperience and human error?

    Steve Jones

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

  • Republish: Not Useless Features

    I’m in San Francisco as part of the Database DevOps Rocks Tour. I’ve had fun taking pictures for the events and managed to make 4 of the previous events. This is my 5th and the 6th for me is Seattle in a couple weeks.

    One of my favorite shots

    IMG_5839

    I’m lightly pointing at San Fran, but I think I was motioning a car to go around.

    In any case, you get Not Useless Features as a republish.

  • Degree Apprenticeships

    I enjoyed my time in college, and I learned a great deal. While I do think that the time helped me grow, I also recognize that I was always a good student and the cost of my working through that degree was far below what today’s degrees cost at many universities (even accounting for inflation). What’s more, I worked most of the time I was at university to pay for my living expenses.

    These days I am torn on the value of a degree, especially when the total cost can easily exceed USD$50,000. Even more concerning is the fact that many people have to drop out with substantial debt and no degree. That’s the worst of both worlds. While it’s easy to point the finger at people for not finishing or working harder, it ignores the challenges of the real world, which can throw curve balls at all of us.

    For a lot of my college time, I had to work to support myself because I didn’t have enough scholarship funding, and I was worried about loans. I was worried about post-college, and in the 80s, I was able to work 30+ hours a week and earn enough to pay rent and buy food. Later in my time, I was able to secure an internship that paid me, which was nice. Then I wasn’t spending 80+ hours a week trying to learn and support myself.

    I saw a note recently about degree apprenticeships from Purple Frog Systems. The idea is that someone is part-time in university while working for an employer. This might require more than 40 hours a week of combined work, but I like the idea of someone learning about both the academic and practical views of an industry and getting mentorship from both co-workers and academics.

    While many of us who work for an organization might get tuition assistance, it’s not always easy to work out school and work. Managers may or may not work with you, and there isn’t really continuous support to help you complete your degree. The quality of your manager often determines if this works. However, the bigger issue is that many people struggle to find jobs in the first place and not many organizations I’ve worked for have any programs to find people who might be suited for an apprenticeship program.

    I don’t that our industry, or many industries, really need to require degrees. That being said, I do think there are things universities teach well, and they give a good perspective on a variety of topics. Employers can benefit from motivated individuals who learn their business, learn different skills in school, and bring about energy and fresh perspectives. Plus, employers learn how to train and grow new people at a lower cost. We all struggle to hire well and train people to be effective quickly. Working with interns or apprentices is a good way to embed regular mentorship and training into the culture of your company. That’s something everyone can benefit from.

    I hope to see more apprenticeships in the future, not just in technology (or marketing as in the post), but in a variety of industries. I don’t know if we will, but I do think this might help us get better at finding and training new staff.

    Steve Jones

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

  • Be Valuable, Not Critical

    I find there to be a lot of value in actively managing your career. I’ve been a technical individual contributor, a manager, a business owner, and a cross-team supporter in my various positions. Each one has challenges, and in each case, I’ve found ways to build a better career position that not only suits me but makes my life more enjoyable. I hope to inspire others to do the same, and this is part of a series of editorials based on advice I’ve read from Raylene Yung (Facebook and Stripe) on your engineering career.

    One of the first things I read was that engineers ought to aim to be valuable, but not critical. This is similar to the advice from others that good tech staff try to work themselves out of a job by documenting and sharing everything. Not everyone is a great, or even good, engineer, so I understand why it can be scary to share knowledge. However, many of us find ourselves doing something that few, or no one else, does anyway.

    Viewing this as being valuable is helpful. However, if you are critical and the only one that can do something, you might find yourself on-call, or under a lot of pressure from management when something goes wrong. Instead, if you have the detailed knowledge, but you’ve shared that in some way, you can be the consultant or advisor rather than the person everyone expects to be doing the work in a crisis. This is a mistake I’ve made many times in my career.

    You want to provide value in some way to your organization, but not be a single point of failure. In the short term, your manager might feel you can’t be replaced, but often I listen to managers talking about their plans to find a way to remove those critical people who don’t want to share their knowledge from that position. Usually, removal also is accompanied by termination.

    Good engineers find ways to be valuable, partially by gathering tribal knowledge, partially by developing solutions, and partially by sharing with others. Document, explain, train, and assist others, but ensure that if you want to go on vacation, sleep all night, or celebrate life away from work, you aren’t the critical person during a crisis or even normal, daily work.

    Steve Jones

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