There’s an interesting piece at O’Reilly this week titled The End of Programming as We Know It. That’s actually a good title, but it doesn’t mean the end to programmers, developers, software engineers, of whatever people call themselves.
The piece looks back at history, starting with physically connecting circuits to program and moving to switch flippers, cards, compiled languages, and on to the web and mobile systems. Each of this brought more and more programmers into the industry because there’s no end to the software needs of the world and it’s hard to write good code.
I like that the web was seen as the end of programming as anyone could easily build a minimal application to share things. Even frameworks like WordPress let novices create applications that do all sorts of useful things. However, we still need programmers. Look around at how many WordPress consultants are willing to help you.
That’s because there’s a difference between configuring something off a shelf (or from a digital store) and actually having a working application for your situation. There’s no end to what people want to build, and really, they need someone to build it for them. Or at least modify, improve, or re-implement the proof of concept they created.
The world of AI LLMs, and chat-oriented programming, is no different. Anyone can ask for an app and get a reasonable prototype. However, I don’t think this means less programmers. While more people will build more PoCs or prototypes, that also means more people will need a professional to clean up their system and make it work, scale, and perform well. And probably help secure it better.
Programmers (developers, software engineers, etc.) will scale themselves with AI tech, as they’ll get the AI to do some scaffolding and initial work that they clean up. I’m sure the very best will build RAG AI systems that generate the type of code they want with a little training and input. I could see millions of AI assistants that help write basis code outlines, write tests, check for standards and code smells, and help the human shift left, catching small, simple, silly mistakes.
I think we’ll have more people producing software in the future, but I also think that those who know their industry well will be in more demand. They’ll recognize issues in AI-generated code, they’ll guide AIs better, and they’ll communicate more clearly with AIs. They’ll get their pick of the best jobs, and they might be better compensated.
Things they likely do today with their fellow humans.
I listened to an interview with Grady Booch. If you’ve never heard of him, he has been a software engineer for a long time, developed UML, and worked at IBM and a number of other places. He has devoted his life to improving software engineering. He even told Bill Gates he didn’t want to be the Chief Software Architect at Microsoft.
At one point he had a less than flattering description of AI LLMs. Politely, they are unreliable narrators. Less politely, he feels that they allow us to build at a global scale, unreliable BS generators. This is because the LLMs that are stochastic parrots, which can produce some coherent results. Primarily they allow us to navigate a very large lake in space, i.e. the Internet. I think that’s true. I have found AIs to be pretty good search engines. Not perfect, but good.
Mr. Booch notes that LLMs, while interesting, are a shadow or a whisper of what humans can do. He’s critical of those who think AI is going to compete with humans. Here are limitations on what the tech can do, and Mr. Booch thinks that the approaches people are taking, architecturally, are wrong. As part of his work, he studies more of how humans work and think as a way of trying to build better software architecture.
Caveat, he does think we can build more intelligent systems, but it’s not with Gen AI/LLM architectures.
I tend to agree with him and do think that the LLMs are unreliable. They appear to be intelligent, but they are more predictive engines in many ways. They can be very helpful in many ways, but they aren’t necessarily replacing smart humans. They might help smart humans replace some other humans, but they are likely to be better assistants than replacements.
It’s a great interview and worth listening to. There’s a walk-through where Mr. Booch touched on computing as well as a very positive outlook on the future of his career and the things that he is working on. It’s long, (1.5 hours), but a fun listen. Give it a go and let me know what you think.
redesis– n. a feeling of queasiness while offering someone advice, knowing they might well face a totally different set of constraints and capabilities, any of which might propel them to a wildly different outcome – which makes you wonder if all of your hard-earned wisdom is fundamentally nontransferable, like handing someone a gift card in your name that probably expired years ago.
These days, as I speak with others as a coach or just community peer, I feel some redesis about any sort of advice I give that isn’t tightly bound in some way to a situation. Any sort of general advice has me wondering if the things that worked for me will work for others.
I recognize that the way each of us see the world varies, depending on your situation. I think EVs are great and convenient, but I’m in a position where I can afford one and afford a charging station in my house. I don’t worry about the price of eggs or bacon, but that’s because I’m lucky. I don’t worry about health insurance because I’m healthy now.
The advice I give people about their careers is always tempered to remember my redesis. The things that worked for me might not work for others, so I’m careful to explain the situations where this worked for me rather than give the advice without context.
The Solutions Engineers at Redgate recently released an Introduction to Redgate Flyway Autopilot course on our Redgate University. They’ve been working on this for quite some time to help people get started with Flyway in their own environment. It’s gotten smooth and slick, so I’m going to set this up in 10 minutes in this post and video, but with a twist. I’m using my schema to show you how easy this is.
I’ve been working with Flyway Desktop for work more and more as we transition from older SSMS plugins to the standalone tool. This series looks at some tips I’ve gotten along the way.
Having a SQL Server or PostgreSQL server (I’ll use SQL Server)
You will also get a Redgate Token and set up a local runner. I won’t detail those steps here, but I will have them in another post. The video will also skip those steps.
Creating a Repository
I’m working in GitHub, but you can do this in Azure DevOps. Others work, but those aren’t in the course. The main thing to do is go to the official Redgate repo at: https://github.com/red-gate/Flyway-AutoPilot-FastTrack
This brings you to this site:
From there, don’t clone or fork, but use as a template. This is in the upper right corner.
When you click this, you get the Create a new repository page, that looks like this. If you’re familiar with GitHub, this looks like any other repo. Give it a name, which must be unique in your org. I added FWAutopilot as I already have an “Autopilot” repo that is public.
You can make this public or private, but just be aware of this from the standpoint of your org, especially if you add internal schemas. You can also set a description.
Once this is created, you’ll see the repo in your org. Here’s my Autopilot repo:
This is a copy of the template all set up. Now, on to Flyway Desktop.
Creating a Project
In Flyway Desktop, I’ll click the drop down by Open Project and select Open from Version Control.
Here I’ll paste in the URL of my repo. I also check that the folder for the local clone is valid. In my case, I tend to put things in Documents/Git, but you might have your own standard.
Once this clones down, you can see a repo in the path above that looks like the online repo. Flyway Desktop will also refresh the schema, which should give you this error.
This is because the databases don’t exist. As you can see, I’ve filtered to databases with “auto” in the name and I have nothing.
If I use the file | open in SSMS, I can go into the repo and into the Scripts folder, where I see this:
I want to open the CreateAutoPilotDatabases.sql script, which looks like what you see below. This creates 5 databases and adds schema objects to one of them. The goal is for Autopilot to use Database DevOps and Flyway to migrate these changes to other databases.
Run this, and I see different databases. I’ve refreshed things, and you can see Prod has nothing but Dev has objects.
Now that I have a db, let’s refresh Flyway Desktop. Now I see no changes.
Note: If you aren’t doing this on your localhost instance, then you can edit the connections to the dev database (and other databases).
Adding Our Own Schema
Don’t start deleting schema objects yet, but you can add your own. I’ll do that. I have a script that contains a schema for baseball data. The beginning is shown below, but I’ll run this in my AutopilotDev database.
After I do this, I’ll refresh Flyway Desktop again and I see my tables. This is a partial list as the full list scrolls off the screen.
I’ll select all these from the checkbox at the top next to Object Name and then click “Save to project” in the upper right. This writes the CREATE scripts for all objects to the schema model, as you can see below in the update message.
The next step (shown at the bottom) is to generate a migration script. I’ll click that.
I get the screen below, which shows me all the changes that have been made to objects. I can select one or more of these to put into a migration script (deployment script). If I don’t select them all, then I will see those I haven’t selected re-appear here and I can add them to a different script. To keep this simple, I’ve selected them all.
When I click “Generate script” in the upper right, Flyway will create a script containing all the objects I’ve selected with the appropriate create/alter/drop code inside. Here is my one large script. You can see the start of the script below. If we scrolled, we’d see the CREATE for all the tables in here.
This project is configured to automatically generate an undo script, so below the above part, there is the undo script. Again, this is just the beginning of the script. However, you can see before we drop tables, we need to remove constraints.
Once I’m happy, I can click save and this is written as a migration script (and an undo script).
I can click Verify, which essentially runs these scripts against my shadow database, but I don’t do that if I haven’t altered the scripts. You can if you want.
Now that we’ve made some changes, let’s commit those. On the right side of Flyway Desktop is the VCS blade. You can see I have 28 changes in my repo.
If I click the “28”, this opens to the commit tab. I can also click the arrow at the top and select the commit tab. In here, I see my changes and I can include all of them or some of them and write a commit message.
I’ve selected them all and written a message, so I’ll click the drop down by commit and select the combined Commit and Push.
If I check my repo, I see this commit included. You can see this altered the schema-model and migrations folders.
Now we need to keep this Database DevOps flow going and deploy our code.
Setting Up Runners
If I check the Actions tab in my repo, I see there are two workflows configured. They are the same, but one works for Windows and one for Linux. I don’t have any runs yet and I haven’t configured a runner.
If I go to Settings in my repo and the Actions | Runners area, I’ll see this. The runners are the agents that execute your code. In this case, I need to setup a new one. I’ll detail that in another post.
Once I have a runner set up, I should see something like this:
Adding Secrets
Flyway is a licensed product, so I need to tell the runner that it is licensed to use the product. If you don’t have a license, this system can get you a 28-day trial, but if you have one, you can just use that.
Note: I’ve deleted this token, so this code doesn’t work.
Don’t close this, but open a new browser tab for your repo. Go to the Secrets | Actions section under Settings. You should see this. Click New repository secret.
The documentation notes you need to add two secrets: FLYWAY_TOKEN and FLYWAY_EMAIL. These are essentially secret variables picked up by the automation. When I click new, I add the email like this.
I added the token in the same way, pasting in the token from the portal. When I finished, I see two secrets.
Run the Automation
Check your production database (and the test one). There should be no objects, which is what we saw above.
Now, go to the Actions section of your repo. Click the Windows workflow on the left (or Linux if you used that).
Now on the right, click Run workflow, and then Run again in the pop up.
In a minute, your web page should show this running with a yellow circle before the name.
Your CLI window should look like this as well, with a job running.
If you click then name of the run on the web page, you should then see the three tasks. Here my build completed before I could get the screenshot, but yours likely has the yellow on the build database.
If I click any of the tasks, I’ll see the logging as they run. In this shot below, I’ve clicked the running prod deploy, as that was running when I was ready for the screen shot.
The output scrolls along and can be hart to follow, but after any of these are complete, you can click on them and see the task outline. Each of these items below can be expanded by clicking on the angle bracket. You can see I’ve expanded the Migrate Test DB task.
However, most of the time we assume we have a repeatable, reliable execution of our migration, so we don’t care. The proof is in checking the databases.
Here is my refreshed AutoPilotTest database.
and here is the AutopilotProd database.
I moved code from dev –> VCS –> test –> prod without executing it anywhere past Dev. This is the way changes should be made to test them before they hit prod.
We should also have feature branches, PRs, and more, but that’s beyond the 10 minutes to get started. From here, I could easily make other changes in dev and get them deployed by clicking a button in GitHub.
Summary
This process took me ten minutes. To be fair, I’d tested it a few times, but in knowing what things are needed in the docs, it took me ten minutes, which I show in a video below.
Flyway is an incredible way of deploying changes from one database to another, and now includes both migration-based and state-based deployments. You get the flexibility you need to control database changes in your environment. If you’ve never used it, give it a try today. It works for SQL Server, Oracle, PostgreSQL and nearly 50 other platforms.
Voice of the DBA 