Tag: software development

I wrote recently about some work with Redgate Clone, and one of the things I did was start up a blank container instance of SQL Server from the image named empty-sql-current. This image contains SQL Server 2019. Clearly, “current” was a poor choice.

I see this often in various places, where someone will reference “current”, “new”, “latest”, or some other term that denotes the most recent changes. If everyone reading the reference is doing so with knowledge of the past and at a time close to publication, this works fine. However, a year later, does this make sense? At the same time, I do like consistent names that might be used in scripts. If I always want developers pulling the latest item, I might use latest. However, if versions are important, than “latest” or “current” might not be the best choice. Much of the time, I tend to try and get a version or some other specific indicator in a name.

It’s like seeing the words “the fastest SQL Server ever” (or pick your technology) in a release announcement. At that time, it might be the fastest SQL Server release, but when the next version is released (hopefully) that won’t be true.

As I’ve matured, I aim to build things that last for the future, thinking beyond what the world looks like right now. This includes architecture decisions and more, but it also includes naming. Reference specific versions, times, etc., with the idea that I want to convey some information with the name. I even name my containers with the port I use because it makes it really easy to see which database container is running on 1433 and which is 41433.

The other consideration for naming, for me, is to include data in the name that I will use for searching or sorting. Perhaps means using good date practices, like 2025-05-01 and 2025-10-03 to ensure my files sort correctly. That might be very important for things like backup files. Maybe it’s using something like “Customer_Copy_Delete_After_Year_Close” for a copy of data that might be relevant through our current financial cycle.

I often do like using names that come to mind first, as this can help me find things, but I also have learned to be more explicit when using names as a way to convey information. With modern computing and support for large names, it sometimes pays to be descriptive.

The only thing I try to avoid is spaces. For the most part, file explorers and web servers handle spaces, but sometimes things break, so I’ve learned to avoid spaces where possible.

Steve Jones

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

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

I ran across an article on the 7 types of tech debt that can cripple your business, which is a great title. It certainly is one that might scare a lot of CTOs/CIOs/tech management. I am sure that much of the IT management gets concerned on a regular basis with how quickly their staff can evolve their software to meet new business needs.

The first two items have to do with data, which is understandable. Data is the core of how many organizations operate and move forward, and if you don’t have the ability to easily work with data in a flexible way, you can struggle. Many of us technical people know this, but I find many non-data-professional staffers don’t get this and are often unwilling to work at improving the situation. They things to just be magically better without changing how they do their jobs.

Many of us data professionals know that data quality is crucial. Many others assume we have quality data. Both of us need to understand that some of our data is suspect, but most of us is pretty good. Don’t get drawn into a black/white argument that our data is amazing or horrible. No matter what we do, there will be errors, so account for that. At the same time, do some testing, some evaluation, and double-check yourself.

We also need to ensure some level of performance from our data stores (databases, data lakes, etc.). Too often we see queries start to slow down and blame the DBAs. We ask them for better performance without being willing to press on developers (or vendors) to improve the performance of their code. Don’t just expect to build bigger machines, make sure you train staff to write better queries and help DBAs learn how to better index systems. We’re a team, so let’s work as a team on our performance issues.

There are a few AI-related items and a couple of DevOps items as well. All tech debt is a problem; it just depends on how much you have as to how big a problem it is for your systems. However, the seventh item is cultural debt. AI is part of this, as staff can have job-threatening views of AI, but that’s really a lack of trust. Management has to build trust with staff and ensure they are cared for if management expects staff to be accountable for code. Workers have to drive themselves forward, as a part of the technology revolution is that change is a given. Don’t expect to do the same job you’ve done for years. Learn to use new tools and learn to use them effectively in your position.

At the same time, management has to value employees and be clear about what’s expected or workers. Be fair with employees and value their efforts. Working together is what will drive your organization forward.

Steve Jones

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

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

I had to make a few changes to a SQL Saturday event recently. The repo is public, and some of the organizers submit PRs for their changes, and others send me an email/message/text/etc. for a change. In this case, an organizer just asked for a couple of image updates to their site. I opened VS Code, created a branch, added a URL for the images, and submitted my own PR. After the build, I deployed it.

And it didn’t work.

I had a broken image. I checked the URL in code and realized I had “events” copied before the URL, which wasn’t valid. Ok, edit the URL to be correct and repeat: new PR, build, merge, deploy.

And it didn’t work.

I was looking at the code live on the site, the code in the repo, and I was trying to reconcile paths and file names and keys and values and a few other things.

I realized the world for a developer hadn’t changed a lot, and in fact, I was in the age-old loop: deploy, patch, patch the patch, fix the patch for the patch, and so on. I don’t even know that I could have gotten better here with testing, as these were one-off data changes that affected the site for users. If I enter the wrong data, it’s wrong. I can’t easily test for this.

I have written code that was wrong, and a few simple tests would have caught my issues. I’ve also written code that isn’t easy to test. If I am adding or changing data, it’s hard to test that. Often, I might do some copy/pasting between the code and the test to generate the test. If I’ve typoed something, the typo continues through the test (in some cases). Even using a code generator or an AI to produce the INSERT or UPDATE code might not solve the problem. They might read my typos in a prompt.

One of the best things to help code quality in the last few decades is continuous integration (CI), where we have automated systems that compile code, test it, and run it. It’s not perfect, but it does help reduce the silly mistakes many of us likely make every day when writing code. These can’t prevent typos and issues, but if we are testing intermediate systems, hopefully somewhere along the way, a human or AI agent tries to verify that the things we were typing exist and can catch a typo.

In this case, I had to find where I’d mistyped the line and realized that I had the path wrong. The image was in a subfolder and I needed to add that to the img url.

Working with data is hard, and it’s a constant source of simple mistakes. I don’t know we’ll ever get away from patching the patch when data manipulation is involved.

Steve Jones

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

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

Many of us are faced with choices and decisions constantly in our jobs. How do we approach a problem? What should we do as a team to get the work done? How do we code or manage or test or do something else with a database?

Maybe more importantly, how long do we spend deciding?

I have seen teams spend way too long (in my opinion) debating options and examining possibilities. I’ve seen them take days or weeks arguing and considering edge cases and move slowly. It seems there is no shortage of reasons why something isn’t done. It can drive me a little crazy.

I was listening to a podcast recently and heard about this technique, which I love.

Get a whiteboard that everyone can see (physical or virtual). One person is designated to write down all the discussion items about the issue. Each person can make an argument for or against an idea for the solution, and nobody can stop that argument from being added. However, nobody can remove anybody else’s argument, and nobody can repeat an argument that is on the board.

This can shorten discussions because people can’t repeat things. I’ve seen far too many debates (arguments) continue in a circle because people keep repeating things or circling back. When no one has anything new, we just take a vote and move on.

I am a big fan of getting things done. Even if we don’t have the best, or optimum, or more efficient solution, we need to get moving. Perfect is the enemy of good enough, and far too often, I find technical people chasing perfection, or near perfection, at the expense of moving forward.

Timebox decisions and get moving. It’s how you accomplish more, and it’s what your employer wants.

Steve Jones

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

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