Voice of the DBA

Tag: software development

  • Don’t Create Workslop

    I remember a time before email. Some of my first jobs were mostly based on paper being moved from person to person. I’m sure some of you remember these envelopes being used to communicate between individuals in an organization. I used those to send and get memorandums from others before we implemented email. Fortunately, our email implementation (cc:Mail) came soon after I started working in corporations.

    Initially, people treated email much like paper mail inside organizations. However, over time, people started to treat email differently. It was easy to send an email around other work, so people started to send more messages than they ever would have with paper. They started to dash off notes quickly, sometimes too quickly, as an email might be followed by another email that includes a “I forgot this”. As instant messaging grew, we saw similar patterns where people were quick to send messages, regardless of whether they were important, well-thought-out, or even necessary.

    As AI becomes more widely used in the workplace, there’s a similar tendency. People are quick to use AI to generate something and send it to others, often without due diligence on their part to ensure the work is at the quality level the other person expects. Some workers don’t double-check what they received from the GenAI tool, and it may not be complete enough to actually satisfy the requirements they were given. Maybe even worse, the result might not be targeted at the problem that was supposed to be solved.

    I ran across an article on workslop, which is defined as AI-generated work that masquerades as good work. Instead of actually being what the organization needs, it’s sloppy, it’s low quality, or it misses the mark.

    To be fair, I don’t think this is an AI issue. I have worked with plenty of people who produced low-quality output that wasn’t good enough for me to use. I’ve seen plenty of people not really try to produce quality results and do a poor job of completing the tasks they were assigned. With AI, they can do it quicker, which can be a problem, especially if they are producing things other employees depend on or need. The result might be some people be pushing their work onto others who have to spend time fixing (or completing) the copy/pasted GenAI results, taking away from the time others might spend on more important tasks.

    In the technical world, we saw that in the 90s with VB6, where lots of technical and nontechnical people produced code quickly for an application that worked initially, but didn’t perform well, couldn’t be scaled to others, and wasn’t stable enough to run every day. Sometimes not stable enough for an hour. I suspect we’ll see a lot of AI-generated code that repeats this pattern. Not because the AI can’t generate good code, but the people using it won’t know how to ask for good code, with instructions about the types of code that create robust applications. They also won’t know (or won’t bother) to check the code for quality.

    My guess is that the GenAI adaptation to lots of work will result in a lot of things produced, but at a lower quality than we might want. We’ll also see this phenomenon create inefficiencies as other workers have to return or repeat work. Fortunately, there is a lot of room for inefficiency in many organizations, so they can likely continue to function.

    Those that learn to use GenAI well to produce higher quality work will do so faster and stand out from their peers. Of course, a big part of standing out is also developing strong soft skills and advocating for your accomplishments. Without that, you might find those who produce workslop, but talk about it well to others will stand out from you.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • PRs Are Like Trouble Tickets

    I’ve spent quite a bit of my career as a DBA/sysadmin/Operations person. However, I’ve had my share of development positions as well. As I work with customers who look to mature their database development to be more like other software development, I’ve noticed that PRs sometimes don’t get handled as smoothly as we might like. In some sense, they are like help desk trouble tickets that never get closed.

    One of the first things I caution people about is specifying specific reviewers, especially DBAs. There are often DBAs who are the gatekeepers for code, but if we require them to be the only ones to review code before a CI or test process, we really slow things down. This often happens in smaller environments where one DBA wants to avoid anything impacting their job. They want to review everything before it commits.

    That’s a bottleneck that will slow you down. Train others, agree on the types of changes that can be approved by multiple people, and learn to handle the problems, not try to prevent them all.

    Another issue is that lots of people are often overloaded with their workload. It’s a big reason people want to adopt a more DevOps view of the world and try to reduce time spent on handoffs and the friction in the process. However, until things get better, they can get worse. PRs can languish when people are overloaded. Like the first item above, choosing specific people for a review can make this worse, but even if you have a group to review requests, you might find everyone expects someone else to look at the request.

    There’s no good solution here, but establishing a rota for reviews or setting aside time in a calendar can help. There will still be cases when you need immediate review, so there needs to be some escalation process, at least until everyone acts like a team and tries to ensure the others aren’t waiting a long time for their work to be reviewed.

    The last thing about PRs that I find similar to trouble tickets is the content. I have had tickets where I have MB of multiple text logs, and at the same time, a bare-bones description like “this doesn’t work.” PRs can be the same way, with too many changes and too sparse a description. Your commit message(s) might not be good for a PR. Use the PR space to give the reviewer some context. Try to limit the changes, though I know sometimes this can be hard. As much as possible, focus on making non-breaking changes in code, tying schema alterations to feature flags so that you can merge in smaller bits of work without breaking the system.

    Learning to create a more mature database development process takes work. Software developers have gotten better, though they still face some struggles in managing their PRs. Learn from them, ask questions, take advice, and above all, work as a team.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Requiring Technical Debt Payments

    I was working with a customer recently that is trying to improve their processes. This was a large company, over 100,000 employees, though most of them aren’t in the technology area. However, across many divisions and groups, there are a lot of developers and operations personnel who have tended to work in silos, managing their own applications and systems in disparate ways.

    In other words, doing software development the way most companies do it.

    I had been working with one group to streamline and standardize some of their software practices to implement more of a DevOps flow to smoothly build, operate, and update their systems. They’ve had some success and other groups noticed that this set of teams is very efficient. They aren’t DevOps like a lot of the articles you read. They still have development and operations, but the groups work closely to ensure efficiency.

    They started to get requests to onboard other teams into their flow as the management of this group has been advertising their success. Other groups want to implement Continuous Integration, get database unit testing and static code analysis setup, implement gates for approval, and more. The Operations team manages most of this and is happy to help other groups.

    But

    They require some things to be in place, some of which are cleaning up technical debt. Not all debt, but certain things that create additional risk or instability. Before they onboard anyone, they don’t want to take on a codebase that is difficult to manage. A lot of this debt isn’t difficult, but they want some good coding practices implemented. They require integrated security or a waiver from InfoSec. They want explicit index names, not system-generated ones. They want permissions granted to roles, not users. Not big things, but little items that make a system less maintainable and understandable.

    The same things a lot of us let creep into our codebase over time.

    On one hand, I thought this was an idea that would slow adoption and allow many groups to continue to operate inefficiently. They won’t clean up code. On the other hand, this might be the lever that helps create a better run environment across the organization. This might help them smooth their upgrade cycles, let staff change between projects, and more importantly, reduce the overhead of communication and work between teams.

    I don’t know how this will work over time, but I am interested to see what happens.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.

  • Reflecting on the Mythical Man Month

    At an event recently, I had a chat with someone after one of my sessions. I had been speaking on DevOps and ways to better structure your team and build software. After the session, one person asked me if I’d read The Mythical Man Month and if I felt we’d gotten a lot better at building software since that book was published.

    I do think we have gotten better, way better, in fact. I caught another review of the book a while back from the Pragmatic Engineer. That review looked at what’s changed in 50 years since the first edition, as well as contrasting the world today. You have to subscribe to read that one, but I’ll give you a few thoughts from me on the book itself and the review.

    Perhaps the most famous part of the book is the notion that adding more people to a late project makes it later. That doesn’t always happen in other fields, where people can tackle separate tasks and get things done. Certainly feeding hay to horses goes quicker with more people. However, in software, things don’t work that way. Perhaps this can work better today if we use microservices and separate architectural sections, but for any single piece of software, this often holds true. Even for microservices I’m not sure it’s true because developers take time to get productive.

    And yet, people still try to add more staff to projects in the hope they’ll complete the application sooner.

    Another great quote from the book is that programmers (developers today) can build castles in the sky. We can use our imagination to create, polish, and re-work in a way that isn’t easy in the real world. That, along with the joy, complexity, and opportunity to learn, are why people program. The Pragmatic Engineer’s view notes that there are other reasons, such as so much of the world uses software that people want to be a part of that, and the career is lucrative. I agree with that for sure. Working with code is a good job in many ways.

    The book notes several challenges to building large systems, such as precise coding, lack of control, dependencies, debugging, and obsolescence from delays. Of these, some are true, but we have tools, like SQL Prompt, that help us avoid poor typing of code (and CI for checking). We also have moved to a much faster pace of delivering parts of a system and evolving them, so we are  often targeting just what our customers need, at an apparent faster pace. I’d also say that being able to deliver something quickly is important, as customers are quick to move on if you cannot.

    One interesting part of the book that isn’t quite so relevant is the discussion about why projects are late. While I don’t know we estimate better, we certainly are better at getting smaller pieces of work done, which might hide some of the delays for larger features. We have so many more ways to track work and ensure we aren’t forgetting what we have planned. There are also many more good managers today that empower their people. These are also the things in DevOps that have vastly improved how we build software.

    Onboarding is a major issue in the book, as finding staff who knew tools/techniques/whatever was hard back then. There just weren’t many people. Today, we struggle to onboard some people, but I’d like to think that it’s not the same as in the past. However, I certainly think database techies in many cases haven’t kept up or learned a lot of core software dev practices, such as version control, CI, and lots of things we bundle into DevOps. At the same time, I think we’ve burdened many people with full-stack development when they don’t have a good understanding of core technologies, like databases and networking. I still think onboarding people quickly is a major advantage for any company that needs to build software and compete with others in their industry.

    In the book, Brooks talks about the 10x engineer, a hotly debated topic in the modern software world. Are some people much more productive? I do think so, though if they are 10x as skilled as many others, I’d argue the others aren’t earning their salaries.

    If you’ve never read the Mythical Man Month, pick up a copy. It’s worth your time as a developer or a DBA.

    Steve Jones

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

    Note, podcasts are only available for a limited time online.