Voice of the DBA

Tag: software development

  • The New Software Team

    One of the things I used to emphasize in talks about DevOps is that no modern software of any significance is built by one person. Everything takes a team, so the foundation of version control becomes extremely important. We need a way to coordinate work across multiple individuals and communicate what changes are being made. This requires a strong foundation, and that starts with version control.

    In 2026, that hasn’t changed, but what has changed is the makeup of the team. No longer do I need a bunch of humans. In today’s world, with extremely powerful AI LLMs, we can have a team of AI agents that write code, often at a pace far exceeding that of human teams. However, they still need to coordinate and communicate and ensure their changes mesh together.

    In this short article on the rebirth of programming, the team is a team of n humans and m agents. N=1, and the architect, the coordinator, the project manager is the human (or a few humans). Code becomes less important, and the tests and other elements that describe and verify software become more important. Maybe even more important than today.

    I’d even go so far as to say the performance of the code might not matter in the short term. Since the cost of writing, or re-writing code, becomes lower and lower, when something doesn’t perform well, just spin off a new team of your agent coders who don’t need sleep, aren’t worse at development if they work more than 40 hours every week, and are always happy to tackle new work. It’s a project manager’s dream team. At least, in theory.

    That being said, the cost of writing this code isn’t zero. We see this rising every day, sometimes at a level that exceeds what we might pay human developers. That might change over time, but we certainly see some people spending more on tokens than salaries.

    And your agents do lose focus. Fortunately, you can fire them and hire new ones every day, or every hour. It’s like a team of characters in a game that respawn on demand to tackle the next challenge. There is still plenty of coordination and onboarding work for the manager. They will need excellent documentation and descriptions of what the code looks like, what needs to be done, and all of your guidelines on how to structure things. Lots of tests are needed, but your team can build them (with oversight).

    It seems like an amazing system, but we’re learning that excellent team leaders who are good architects are in short supply. And they can’t work long hours. Some early evaluation of these software managers seems to indicate that they can’t even work the full 8 hours for 5 days a week with a high level of effectiveness. They might not even be able to work half that amount of time.

    So is the falling cost of code going to produce more software? Likely, though perhaps with many more leaders needed to manage those teams. I can certainly see many more one person companies spawned during off hours, where one person can focus on their passion project, something completely separate from the work they are paid to do by someone else.

    It’s going to be fascinating to watch this work itself out across the next decade.

    Steve Jones

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

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

  • Every Database Has Problems

    Every database platform has some strengths and weaknesses. Some more than others. I caught this site (NSFW) from Erik Darling, and it made my day. I was having a tough one when this site got me to smile and chuckle out loud a few times. I especially like the MySQL and SQL Lite links (again NSFW).

    Every platform that you might choose to use to back an application can work in many situations. Certainly scale and load are factors to consider, but for the major relational database platforms, most will work fine for many applications. Some might work better than others, but there are always tradeoffs. There are pros and cons. This is also true for the major NoSQL platforms, though most of my experience is with relational ones, so I tend to lean in that direction.

    At the same time, any platform can fail horribly.

    What’s the difference? Quality database design and software engineering. If you have a knowledgeable staff that works with the platform, they can likely make it work well. If they don’t consider the database impact when they code, or aren’t skilled with that platform, they can easily make it seem like the database doesn’t work well at all. Lots of hardware can help, but it often can’t outrun poor data models, poor query structures, or a lack of indexing.

    Quality of code matters, as many data professionals know. We often aren’t given enough time to do the job right, but we know that’s the case. It doesn’t do any good to complain or bemoan the fact that there is never enough time to fix things or improve them.

    We need to write better code to start with, which means learning to write better code. Understand what impacts performance, where you can change your patterns and habits. Watch Erik’s posts, learn from Jeff how to build test data sets to stress your queries if you don’t have good test data. Learn to do a better job in the same amount of time.

    Changing platforms won’t magically fix things, no matter what your CTO/director/manager thinks. Especially if your team doesn’t already have experience on the new platform.

    Steve Jones

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

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

  • Working Better Under Pressure

    One of my colleagues wrote a great post about DBAs and developers, about how a DBA’s pushback on bad code isn’t to be difficult, it’s because they can see the future. I never thought of myself as a modern-day Nostradamus, predicting the future of system performance. Apparently I had another title besides DBA.

    Working under pressure and with short deadlines often leads to short cuts. I’ve made them. I’ve implemented quick hot fixes. I’ve forgotten to port changes back to development databases. I’ve increased our tech debt load, just to solve a more immediate problem.

    The challenge is cleaning things up later, when we have more deadlines and things to fix. It seems that we never have enough time to do the job the way we would like, and there’s certainly no time to go back later and fix things. Most management won’t make this a priority until things get so bad that we have to rewrite a lot of code (which we should never do).

    DevOps, pipelines, automations, and yes, AI, helping can reduce some of the tech debt we create if we use those tools appropriately. Which is a big IF. Often we have more immediate pressures that prevent us from finding time to invest in our systems or in ourselves.

    Getting a handle on bad code, checking it early, and doing so every time with automation can help prevent some of these issues, even when we are in a hurry. That’s why it pays to adapt our work and learn from others. Listen to that DBA that keeps your systems alive. Listen to the DevOps engineers that want you to automate things. Certainly, make them prove their suggestions work, but adopt those patterns. Learn to work with them, rather than against them.

    They can see the future.

    Steve Jones

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

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

  • Who is Irresponsible?

    There was a post on X recently from a founder in the EU about an engineer using Claude and ChatGPT to build a feature. I am not sure how true these posts are or if they are designed to just create engagement, but it’s still an interesting topic. The part that makes me think is that (supposedly) the engineer was fired because their “data” (code) was sent to American servers. The code was then deleted and the feature will be built without AI.

    First, read some of the responses before you form an opinion. There are some funny ones in there. There are a few I think are overblown and silly, and I skim past them. Someone is always more upset than I am, and more than I think they rationally should be, so I tend to let their outrage flow by me.

    There are two interesting things here. First, the debate about sending data to America. There certainly is some cause for concern here if data is being sent to a place outside of the EU where GDPR rules might apply. There possibly could be some legal issue here, though I doubt some of the responses about all code being compromised are an issue here. I don’t think code is PII, though if it were re-used or appears in AI output, perhaps investors could sue this company.

    The second thing here is whether someone should be fired for doing this. There might be a policy and some training about not doing this, and in that case, perhaps the person should be fired. However, I find this kind of thing happening too often, and it’s the type of thing that has happened before AI where people used outside sources (SQL Server Central, Stack Overflow, etc.) to post code in a question and get an answer. And then often use that code without changing or testing it.

    Is this rational? Some people might say yes, some no, many unsure. In the past, before AI, what would you think? To me, sometimes there have been solutions engineers have found but couldn’t use code written by someone else. There are real IP/copyright concerns here. You could rebuild the solution, rewriting the code, which in some sense is what Google did with Java APIs and successfully defended that effort. If another human or an AI gives you code, can you rewrite that code, keeping the same idea for the solution?

    I think that in most cases this is acceptable. I use AI for a lot of things and I throw away a lot of AI output, but it often gets me started down a path, whether in writing, coding, or something else.

    Who was more irresponsible here, the founder or the engineer? I think the former.

    Steve Jones

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

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