I remember a time before email. Some of my first jobs were mostly based on paper being moved from person to person. I'm sure some of you remember these envelopes being used to communicate between individuals in an organization. I used those to send and get memorandums from others before we implemented email. Fortunately, our email implementation (cc:Mail) came soon after I started working in corporations.

Initially, people treated email much like paper mail inside organizations. However, over time, people started to treat email differently. It was easy to send an email around other work, so people started to send more messages than they ever would have with paper. They started to dash off notes quickly, sometimes too quickly, as an email might be followed by another email that includes a "I forgot this". As instant messaging grew, we saw similar patterns where people were quick to send messages, regardless of whether they were important, well-thought-out, or even necessary.

Read the rest of Don't Create Workslop

Over the last few years, I've worked a lot with various customers on finding better ways to build database software, often using the principles of DevOps to drive the change. A lot of managers and leads want to see a smoother process to help their teams become more efficient. DBAs often want less overhead and friction in the process, while developers just want to deliver code.

In many cases, however, what lots of management wants is speed, and they're looking for ways to increase their current speed and deliver more software. Their current rate of development might be quick enough if you can reduce your bottlenecks. Making communication easier, limiting the slowdowns from handoffs, and reducing the risk of mistakes are everyone's goals.

However.

Read the rest of Being Mindful of Design Time

Imagine that you are about to tackle a new project that will take more than a year. This might be a new system, perhaps a cloud migration, or maybe it's rewriting something that doesn't work well. You don't have enough employees to undertake the project without overloading everyone. Your team needs to grow.

Would you rather hire a more senior person from outside the organization or pick a junior person that's already inside your company and teach them what they need to know? Think about this as if you were the one making the decision about the future direction of your software team. Philosophically, do you want to buy experienced people or train/build new ones from your internal staff.

Read the rest of Internal Staff Growth

I ran across a thought-provoking post from Chrissy LeMaire asking if we should reconsider SQL Server HA. The post actually asks if you've considered not using it. The default from Chrissy, for most installations, is to use standalone SQL Servers. This isn't to say she's against HA solutions (FCIs or AGs), but that they often cause problems and might not be needed.

It's an interesting position to consider. For a long time, I avoided SQL Server clusters as they were hard to setup with a lot of complexity, hardware requirements, etc., and didn't really provide enough benefits over using log shipping with a second server for me. These days I have clients with mostly AGs, and they seem to run fine. That being said, Chrissy notes that after she left a job, a network outages caused a bunch of downtime. I could see there being downtime, as the old database mirroring (and the it-will-never-die replication) needed a working network. If you have network issues, you better know how to manage your HA technology's issues.

Read the rest of Do You Really Need HA?

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.

Read the rest of Poor Name Choice

There is a ton of hype now about using GenAI for various tasks, especially for technical workers. There are lots of executives who would like to use AI to reduce their cost of labor, whether that's getting more out of their existing staff or perhaps even reducing staff. Salesforce famously noted they weren't hiring software engineers in 2025. I'm not sure they let engineers go, but it seems they did let support people go.

For many technical people, we know the hype of a GenAI agent writing code is just that: hype. The agents can't do the same job that humans do, at least not for some humans. We still need humans to prompt the AIs, make decisions, and maybe most importantly, stop the agents when they're off track. I'm not sure anyone other than a trained software engineer can do that well.

Read the rest of Data > Hype

I wrote recently about a bad first day for an intern. He/she was fired, without cause in my opinion, when a production database was damaged while following a document for developer setup. The situation felt like a mistake, and one that wasn't necessarily the fault of the individual. To me, this was extremely poor handling of the situation from a CTO.

In the discussion for the piece, someone pointed out that it might not just be a new employee who makes a mistake that causes downtime. Certainly, an inexperienced employee could have caused the issue, but I know there are plenty people with lots of time in a position who make similar mistakes. It could be that one who has been there a long time followed a poorly documented procedure for the first time, or applied the procedure to the wrong situation. Often, I find these are relatively simple mistakes because someone isn't as familiar with a protocol or skill as another person assumed they were.

Read the rest of Practice Until You Don't Get It Wrong

I ran across this article on a survey about AI usage recently. The headline is this: 55% of businesses admit wrong decisions in making employees redundant when bringing AI into the workforce.

That sounds a little ominous for those making these decisions, and a lot of you might be saying, "I could have told you that. Using AI to replace people is a bad decision." On the surface, I agree. I dislike the idea that companies will opt for a semi-competent AI bot or agent to replace people, thereby further exacerbating the challenges faced by many workers in the modern world.

Read the rest of The Selfish Case for Learning AI

Cloud costs are high and growing. Some orgs think they're out of control and are trying to limit spend. Some orgs are looking to leave the cloud. A lot of IT spend over the years has been seen as a cost center, with many executives trying to limit the growth or spend, even while they aim for digital transformations of their businesses. Throughout my career, it's been interesting seeing the tension of groups trying to take advantage of technology and the finance departments trying to manage costs.

The cloud brings some of the same debates/arguments/concerns to the forefront. Partially because of scale, as we can add cloud resources much quicker than we can with a CapEx purchase. Partially because we've also often lost some control over budgeting with the move to OpEx and subscription things.

Read the rest of Reducing Cloud Cost

DevOps can mean a lot of things, but I find in practice that this results in a team using Continuous Integration and Continuous Deployment/Delivery using automation to check and evaluate your software in some way. This should result in quicker delivery of updates and changes to customers, better agility, and higher quality of code.

That last one only comes if you use testing and try to ensure your code is well-written. It's easy to just use DevOps to throw out more poorly written code that doesn't perform well.

Read the rest of DevOps is DevOps