Voice of the DBA

Tag: software development

  • Eight Minutes

    When I was at the Small Data 2025 conference, one of the speakers was talking about their work with AI technologies. This person uses it a lot in their day job, often to complete tasks that they would have struggled to work on in the past, mostly because of time constraints, but also a lack of resources. Sometimes this person has an idea, but doesn’t want to distract themselves or others by having them work on a side project.

    During a recent ride in a Waymo (self-driving car), this person had their laptop out and running Claude Code. They gave it a prompt, asking it to build a small app for some data analysis. During the 8-minute ride, the agent had spit out the code, a Readme, and committed this to a git repo. Later, the speaker tried it and found it solved most of his requirements, and then did some other work on the project, as well as having Claude write more code to get something that was beyond a minimally viable app.

    He then gave us this William Gibson quote: “The future is already here — it’s just not very evenly distributed.” I’ve thought about this quote a lot during the last few decades, especially as mobile phones and apps have become prominent. In Colorado, the bandwidth and connectivity have lagged behind other places. When I get frustrated with the mobile network, I want someone to put a copy of that quote above every developer’s desk at Google, Microsoft, Meta, etc. so they realize the way things work in Silicon Valley isn’t how they work elsewhere.

    I’ve been feeling that way about AI tech lately. It’s the future, and it’s not well distributed. There are some successes out there, among lots of failures, but I suspect that some of this is that we’re all working with unevenly distributed models, knowledge, and problems. Some of us are learning to use things better than others.

    So I’m wondering, what do you think you could do in 8 minutes with a coding agent? Take a Waymo if you want, but you might be more comfortable with Claude Code (or another agent) at your desk. Take a problem you’ve been working on and give it to the AI agent. See what happens. Maybe even tackle a side project you can’t seem to find time on which to work and see what happens.

    As I started this, I actually kicked off Claude Code and asked it to load some data from messy files into a database. Across a couple of days (I started late one afternoon), I estimate I spent 10 minutes approving actions, but for less than $5, I had a lot of data loaded (88 files) and the code to do it committed in a repo. With very little effort from me.

    Think about what you could do in a few minutes with an agent. You might get something useful, with little effort or cost. It probably would not be a production-ready app, but it would be something to test an idea, or maybe some code that might inspire others to tackle some of their own backlog.

    What do you want an agent to help you build?

    Steve Jones

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

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

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