Voice of the DBA

Tag: software development

  • Your AI Successes

    Recently, I was discussing AI with a friend, and they asked me to name a great success of using AI to build software. I’ve tried a few things, and I’ve worked with customers who are using AI tech. However, most of the things I’ve seen built with AI are small tasks; they’re utilities or quick wins that change a minor part of the software. The items tend to be tactical and focused in a narrow band of fixes, and they might save a programmer time, but I’m not seeing large-scale team improvements in productivity.

    Yet.

    I think there is a chance for AI to dramatically change our industry, and perhaps help us tackle a lot of small things we haven’t wanted to, or been able to, find the time to build/fix/change/etc. Certainly, in the area of migrating from one version of a platform or framework to another, GenAI can be very useful. This can be a very tedious task, and one where humans can make lots of small mistakes. An AI agent likely can do this quicker, cheaper, and more accurately than humans. The question might be whether this is a huge success, as any single organization might do this rarely.

    The biggest success in many organizations might be the ability of developers, or even business people, who can quickly build out an MVP of an idea to see if there is a project worth pursuing. These often won’t have the robust coding or security practices embedded, but they can perhaps shortcut putting more research into an idea until some value is proven. At least internally, if it doesn’t have good scalability or security, it shouldn’t be exposed publicly until it adds those capabilities.

    When or where has an AI worked best for you? What impressed you about the AI technology interaction that changed how you might work in the future? Or perhaps if you’ve had a big failure and want to share, where did AI not work well?

    I think most of my experience is that AI is still a bit of a toy and useful in small ways, but it hasn’t proven to me that it’s worth the hype we see in so much of the media. Maybe it will at some point, but so far this seems more of a dream than a reality for software professionals.

    Steve Jones

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

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

  • Minimally Viable Security

    Security has been a constant concern for many IT professionals over the years. Many of us are trying to implement better security controls, and yet at the same time, we try to avoid anything that slows us down. Security clearly hasn’t been a big enough concern, as we’ve had more than our share of SQL Injection issues. These often come about from poor practices, lack of education, and too many people not learning to adopt better habits across time.

    We’ve also had no shortage of lost backups, open cloud buckets, and more over the years. While security (or cybersecurity) is listed as a concern for tech management, they are quick to avoid slowing down any development or deployment of software. While it is easier to get time for patching these days, it’s still not easy. There are plenty of organizations that prioritize resources spent on tasks other than patching, upgrading systems, or training developers.

    One of the ideas in modern software development is to often build an MVP, a minimally viable product, where we can test ideas and determine if our solution is worth pursuing. This could be a greenfield application, or even a feature enhancement to an existing system. In the age of GenAI, vibe-coding, and more, this might be MCP or agent-based AI additions to software that are being developed and enhanced rapidly, incorporating feedback from customers.

    If we allow minimal amounts of features to test things, shouldn’t we have minimal levels of security as well? That’s the thrust of a blog post from Forrester that discusses how we might look forward in 2026 to protecting our digital systems. There ought to be a minimum set of controls, testing, and more that ensures we can build software that doesn’t cost more from security issues than it generates in revenue. This might be especially important in the age of GenAI-coding where we can have less experienced engineers or even helpful agents committing lots of code they expect to deploy to production.

    Education is important here to ensure everyone is aware of your MVS (minimal viable security) before they get too far along. It might be especially important in helping others guide their GenAI tools to ensure security is being considered early on. Adding in security requirements as a standard for your tools, such as in a Claude.MD file is a best practice that should be required for all future software development. You never know who might start to add AI coding tools or agents to your codebase, so be prepared now.

    Education isn’t enough. It’s too easy for someone to forget what they learned. It’s also easy to assume many people have learned something when they haven’t. To me, part of an MVS is ensuring you have a framework or platform that can test all code and ensure that your systems are being securely built and deployed. This includes third-party software, especially SaaS products, where vendors might be tempted to sell you their own MVP without any MVS.

    Steve Jones

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

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

  • Don’t Let Corner Cases Drive Your Design

    If you graph computer/query cost against the size of data, you can get four quadrants:

    1. small data, small compute (most CRUD app queries)
    2. small data, big compute (complex BI queries for this quarter, most reporting)
    3. big data, small compute (logs, audit data)
    4. big data, big compute (complex BI queries across all our data)

    If you examine the costs here, 1 is the cheapest, with 2 and 3 having a similar cost. Number 4 is expensive, and it’s why we often have big boxes running our database server software. However, where is most of our work? The majority is in quadrant 1, with 2 getting the second most action. 3 might rarely exist, as does 4, but we often design for 4. We have to as we don’t want phone calls, ever. What we want is to provision a system large enough that we don’t hear many complaints about performance. On premises, many of us have over-provisioned systems to handle the peak load to avoid phone calls.

    Can we handle the peaks or the really important things that someone thinks are important? Everyone thinks their workload is important, and it is. To them. However, there are plenty of cases where someone could think about designing for specific types of workloads, rather than just aiming for quadrant 4. I’ve got an image of different types of workloads that I grabbed from the Small Data 2025 conference. For example, if I am working with things like Time Series data or streaming analytics, I might not need huge compute. I might be storing a lot of data, and I need space, but the compute is low. The analysis of that data, however, might be compute intensive.

    This is a reason why we might separate analytic systems out as they often are in quadrants 2 and 4, and we might want serverless or scale up/down systems to handle the rare cases, and get a real cost for them. I found it particularly interesting that the Bronze tier might be where we have big data and big compute, but once we’ve moved to Silver or Gold, we might have lower compute and data requirements. This makes sense as Bronze is more staging, but it is a good reason why we might aim for a Gold layer in our organization and only keep that data for the long term; it’s more cost-effective.

    Often, for simplicity, we build a bigger system for all types of queries. In other words, we are letting corner cases drive our design. That might be required, but it might not be. In this area of cost concerns, especially in the cloud, designing systems with appropriate resource usage is something that might override the analyst’s desire for queries across all data running as quickly as order lookups in an OLTP system. This might be even more true if we can predict some patterns in our workloads during system design. We can’t scale up or down instantly, but in a lot of places, I wish I had been able to scale financial or reporting systems up for a few days as we close out the period and scale them down for the rest of the month.

    When building a system, think about the practical nature of your requirements and assign a cost to them. Let users know what workload you’re building a system to handle and set expectations on performance and cost. If you do that, you can let others decide when we handle corner cases and when we don’t. That’s often a much easier conversation when we have cost numbers to help customers understand the implications of their request.

    Steve Jones

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

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

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