Voice of the DBA

Category: Editorial

  • Code Building Code

    The dream for some people is to have an Artificial Intelligence (AI) system that you use to describe some requirements and it will build an application that meets your needs. Certainly some AI and ML systems have reduced the need to write code for portions of an application, but I don’t think there is any AI framework that can build an entire application from scratch.

    I was reading a blog post recently on using metadata in our database to produce a CREATE TABLE statement that could hold the output of a query. It’s not AI, but this is something I’ve done in the past, using code to help me get work done.

    Excel was one of my earliest helpers and still is. I find myself sometimes using Excel to build a series of statements that follow a pattern, but the contents of which might be based on some result set. A common example is a set of inserts based on some data. I use values in cells to build up a final statement and then copy these to SSMS or another tool and execute them. It’s quick and dirty, but it works well.

    In the past I have written code that would build other object code, usually to provide some API constructs for developers. In a few environments, we have had some standards about how to structure tables, views, and stored procedures, including at times an API-like standard that required certain functionality be implemented in stored procedures. Using a code writing stored procedure allowed me to quickly ensure that the required stored procedures were created and modified as tables were added or altered. This also ensured that we kept all these changes in sync, without depending on my to review every part of the API.

    I don’t know that I’ll see a true AI system that we can give a few specifications to and have it build a system, but the more we implement standards and known structures, the more we can use code to help us ensure those standards are implemented in a consistent manner. Using templates in our work, such as powerful snippets in SQL Prompt, along with code analysis that looks for poor practices can help us write better applications. Even if it doesn’t do all the work, these helper tools certainly improve the quality of the code we do write.

    Steve Jones

  • Trunk Based Database Development

    Early in my career we had a folder that contained our source code. Each of us developers would copy the folder to our workstation and work on our code. To prevent issues, we had read only access to the main folder.  When we thought work was finished, we had to set up a meeting with two other developers, print our code out, and go through a review. If we got two sign offs, we would send our code to a manager to copy into the main folder. Since we were assigned work in different areas, conflicts were rare and this mostly worked, although it was slow.

    Over time I evolved to use various VCSes (Version Control Systems) for development work, with different paradigms for working in teams. These at times included code reviews, but like comprehensive testing, these were optional (and often ignored) when time was short. As an industry, I think we’ve gotten better with code reviews in some sense. The popularity of git and the integration of pull requests (PR) has made it more likely that others will review your code as a habit rather than a rare activity. I certainly see constant calls for someone to examine a PR in the Redgate Slack channels.

    I think this is a good move, but I was listening to a few people talk about trunk based development recently, which has less of a chance for code reviews. In this model, developers commit their changes directly to the copy of code everyone is using. In a PR model, developers work in branches, and only have a PR is reveiwed, is the changed code merged with existing files.

    Trunk based development is a more trustworthy model. We trust developers to make changes to the code everyone is using. This is often what many of us do in database development when we have shared development databases. A change made by one developer is visible and affects everyone else. While some organizations struggle with conflicts, this does ensure that problems are visible early and that your team must learn to communicate with each other.

    One way isn’t better than the other, and if you aren’t familiar with one of them, give it a try. Work on a small PoC with someone else and experiment with how well you can make changes and what conflicts come up. Many of us get stuck developing code in a singular way unless someone forces us to change. The software development process has evolved a bit over the years and you might find that a different style of putting code together may suit your team better.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.0MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Republish: Aging Software

    I’m up in the mountains today, spending some time with family. You get to re-read Aging Software.

  • Giving Computers Ethics

    I was reading a fascinating paper recently about autonomous cars. I’m actually excited about having a car that can drive itself, though I think this is likely quite a few years away, despite the hype. Ever since I read Red Thunder, I’ve thought that we would first get full time autonomous cars that would either be limited in where they were in use, or part-time autonomous cars that could only be self-driving in certain places. Dense inner cities, or maybe isolated highways might be good places to try this, in my mind.

    While we want to do some programming of these cars, we also have a lot of AI/ML systems in place that run models trained to react in certain ways. They identify things that are moving and stationary, trying to determine how the car should navigate and react. The systems aren’t quite as tightly programmed as many of us expect, with if this then that logic. Instead they have guidelines that are decided upon by the designers and then reactions to data inputs and analysis are a little more fuzzy.

    What are the goals? Well, in most cases they are just moving the car safely down a road. In crisis situations, it’s a little more murky. What happens when collisions are unavoidable? How should the car react? Humans often panic and do strange things, but we don’t want erratic behavior from automated systems, so what should we set as goals? There’s a bit of research that was done to ask humans what they would do when they can consider the situation a little more slowly.

    In short, humans make different decisions in different cultures. There are clusters and tendencies in different parts of the world, which is interesting. While people are people and behave similarly in many cases, we tend to value different things, depending on our views of the world. That can be problematic when we start to expect computer systems to be more consistent or predictable. After all, we should decide how computers react and be able to trust our decisions are followed. It is up to humans to imprint our ethical desires as a society on computer systems.

    This is an area where I feel AI and ML systems are moving faster than our ability to comprehend the implications. I would want to have a framework built for automated systems, certainly cars, and then expect all vendors of systems would implement that framework in their vehicles. However, this goes beyond cars, and in any places where we are using software, AI/ML based or not, we ought to publish a comprehensive outline of the way in which our system works.

    Computers have the capability to improve our world and reduce chaos, but only if we agree on the way in which these systems work, and disclose in a transparent way what data they handle and what decisions they make based on that data. I hope that we start to get better about informing the world the goals and operation of our systems. I’m not sure that will happen anytime soon.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 5.6MB) podcast or subscribe to the feed at iTunes and Libsyn.