A series of episodes that look at databases and the world from a data professional's viewpoint. Written and recorded by Steve Jones, editor of SQLServerCentral and The Voice of the DBA.

Many of us know that testing our code is important. The adoption of unit testing by many software application developers as a normal course of business has dramatically improved the quality of applications. Mobile software, especially, has benefited from the requirement for most software to include, and constantly run, a suite of unit tests. For database software, I find relatively few organizations formally test their database code. A few people have adopted tSQLt or the Microsoft Unit Testing Framework, but most don't bother. In fact, many queries that are embedded in application code, or built by ORMs, aren't tested beyond a developer looking at the results from their own (limited set of) test data. That often doesn't catch errors until someone in production runs their application against a larger set of data. Read the rest of Testing is Becoming More Important

Why do we reboot machines when something goes wrong? I'm sure all have done it, and I would guess quite a few of you have found situations where this seems to fix issues, but there isn't an underlying root cause that you can pinpoint. This is a fairly accepted way of dealing with issues, but have you thought about why this is a way to solve some problems? The main thing that a reboot does is return the system to a know starting state. It's why quite a few people complain about some modern laptops and mobile devices because they avoid restarts and try to sleep/wake instead. Most software expects to work on a stateless machine, so restarts help find a known good state. Read the rest of Can You Let Go of Determinism

This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month. We did photoshoots at Redgate many years ago. We had a bunch of props, including some phrases written down. We could create our own, but my handwriting is atrocious (likely why I never became an architect), but I ended up with this one: Read the rest of Doing Good at SQL Server Central

Many of you reading this have a number of years working with technology. You might have 1 year or 20 years, but you've likely grown and learned along the way. Some of you may also know someone who has several years of seniority in a position but not that many years of experience. In this case, a person might have been working at this job for 5 years, but they really have one year of experience that's been repeated 5 times. That's been a common complaint over quite a few years from people who interview others. They find candidates often have very limited experience, yet are applying for senior roles. These candidates are ones who have just a few years of experience, but have ended up repeating those few years over and over. Read the rest of Engineer Lessons

This is part of a few memories from the founders of SQL Server Central, celebrating 25 years of operation this month. When we started SQL Server Central, our goal was to build a great resource that helped other people advance in their careers and also made some money. Our decisions in building the site were based around the digital world and treating the community as we would want to be treated. Over time, however, we realized that continuing to grow this business was hard in a digital-only world. We experimented and proposed helping others build similar sites, like ReportingServicesCentral (which would have been great) or NotificationServicesCentral (which would not), but ultimately, we weren't experts enough in those areas and couldn't find people willing to partner. Everyone thought they could do it themselves and that the knowledge was the hard part, and execution was easy. The truth is that the reverse is the way it works. Read the rest of Expanding into Print

I tend to be fairly careful with data, especially data on this site. When we started the site, we were worried about potential issues and worked hard to ensure we kept our systems safe and limited the attack surface area for personal information. We also declined the various offers we had to sell our list of subscribers to marketing firms. We know that some places add value for marketing, but some abuse the trust of their users and our approach was always to be careful. When we sold the site to Redgate, we emphasized the need for this trust, and to date, Redgate has been a great steward of your personal information. I regularly field requests for uses of data from other marketing people, and almost all get declined. I've had a number of great managers who have supported me on this because we value your privacy. Read the rest of The Power of Data and Privacy

I remember getting a job at a startup in the Denver Tech Center. This was shortly after SQL Server 7 was released, with a marketing campaign that the platform was auto-tuning and wouldn't require a DBA. My colleague asked me if I wanted to learn Cold Fusion and have a longer career. I declined and stuck with this SQL Server thing, which has seemed to work out pretty well over the years. I was reminded of this when I saw a "Death of the DBA Again" post, this time from an Oracle DBA. There are plenty of links in there from Larry Ellison and Oracle about how some version of Oracle won't require a DBA. I've seen questions on Reddit (and elsewhere ) about this topic where people seem to think DBAs can be replaced. Or maybe they want them replaced. Read the rest of The DBA is Dead; Long Live the DBA

Read the rest of When SQL Server Central Went Down

There have been a lot of features added to the SQL Server platform over the years. Several of these features let us perform functions that are beyond what a database has traditionally been designed to handle. SQL Server has had the ability to send emails, execute Python/R/etc. code, and in SQL Server 2025, we can call REST endpoints. Quite a few of these features (arguably) are more application-oriented than database-oriented. There's nothing inherently wrong with having a server perform some of these functions, and there have been some very creative implementations using these features. I recently ran into one of these examples from Amy Abel, where she shows how to use the new REST endpoint feature to call an AI LLM to generate and send emails from your database server. That's creative, and it's reminiscent of the numerous examples from various experts over the years who demonstrate how these features can be used to accomplish a task. Read the rest of Expensive CPUs

The oldest article we have on the site is Tame Those Strings! Part 4 - Numeric Conversions, by me. It's dated 2001-04-18, though I think that's a date we picked when we converted all the content from one database to another. The founders agreed sometime during Feb 2001 to jointly run SQL Server Central. Since we each owned the copyright of our articles from another site, we migrated several articles to build up our content library. This was back when Andy, Brian, and I all had full-time jobs and managed the site during breaks, nights, and weekends. That was 25 years ago. Twenty. Five. Years. Read the rest of 25 Years of SQL Server Central

I was reading Andy Pavlo's end-of-year review of the database world. He's done this for a number of years, and there are links to previous recaps in the piece. He is an associate computer science professor at Carnegie Mellon University, working on quite a few database-related projects. In the review, he tends to track the database world from the perspective of business success and money. There are certainly parts of it that discuss technical changes, but my overall impression is more about the business and usage success than it is about the way database systems work. The main thing that struck me after reading the review was how many database systems there are in the world. I hadn't heard of any of these: RaptorDB, TigerData, Tembo, StormDB, Translattice, FerretDB, DocDB, SpiralDB, Tantivy, SkySQL, HeavyDB, and more. I'm sure I missed listing some I didn't recognize, and quite a few of these are PostgreSQL-based systems, but still, that's a lot of database systems that exist and are having success. Read the rest of There Are a Lot of Databases

AI is everywhere, and if you spend any amount of time looking for answers on the Internet to your coding challenges, you've likely encountered a lot of poor, average, good, bad, amazing, and just-helpful-enough AI content. For awhile, I was avoiding the AI summary from Google as the quality seemed slightly off, but lately it's gotten good enough that I tend use it to decide which links to click on in the results. The summary helps me better understand the context Google sees in my search query. I ran across a post on coding documentation and how helpful these docs are in onboarding, code reviews, and more. The teams that worked smoothly together often had good docs that helped them function as a cohesive group. At least to some extent. Over time, teams start to depend on tools and lose some of that cohesiveness since they rely more on tools than docs. I agree with the piece that this is a part of the reason many teams don't really function as teams over time. Read the rest of More Documentation is Needed

There's concern about the future of AI and how it may affect jobs and employment for the masses. I see plenty of people on both sides of the issue. Some are sure AI technologies won't replace people; some are concerned their jobs will be eliminated, and some are hoping that we will eliminate some jobs and create many more. Sometimes that's the same person. Read the rest of Deep Learning and Craftsmanship Matter

I've had the fortunate, or maybe unfortunate, experience of being thrown into a few jobs with no training. At a couple of my bartending jobs, I had to start working without any training, calling over someone to help run the ordering machine while I made and served drinks. I managed to slowly learn how things worked throughout that first shift, so I was ready to work on my own the second night. I had a similar experience at a tech job, starting as the lead DBA/IT Manager in a crisis, having to try and solve problems after ask others how things were supposed to work. I ended up fixing a bit of code, adjusting networking, and directing others on my first day. When we have a crisis, we often learn a lot from the situation. I've been through crashed upgrades, virus breakouts, hardware failures, and more in my career. While each was stressful and often not enjoyable, I learned a lot each time and came through the incident a more capable developer/DBA/whatever. When we work through a tough time, we are often better equipped for the next time something goes wrong. Read the rest of Learning From Breakage

When I was at the Small Data 2025 conference, one of the speakers was talking about their work with AI technologies. This person uses it a lot in their day job, often to complete tasks that they would have struggled to work on in the past, mostly because of time constraints, but also a lack of resources. Sometimes this person has an idea, but doesn't want to distract themselves or others by having them work on a side project. During a recent ride in a Waymo (self-driving car), this person had their laptop out and running Claude Code. They gave it a prompt, asking it to build a small app for some data analysis. During the 8-minute ride, the agent had spit out the code, a Readme, and committed this to a git repo. Later, the speaker tried it and found it solved most of his requirements, and then did some other work on the project, as well as having Claude write more code to get something that was beyond a minimally viable app. Read the rest of Eight Minutes

JSON seems to be everywhere these days. Many application developers like it across all sorts of languages, C#, JAVA, Python, and more. They use it for transferring information between systems, and are comfortable serializing hierarchical object data into JSON from text and de-serializing it back into its various elements. For those of us working in relational databases, JSON seems like a blob of information that isn't easily queried, indexed, or stored. We prefer working with a relational set of data, which brings us into conflict with software developers. We'd like them to convert their objects to a relational structure, and they'd like us to just work with JSON. Read the rest of JSON Has a Cost

I came across a post recently on the Microsoft Fabric blog about the evolution of SSIS 2025..I hadn't heard much about SSIS in SQL Server 2025, so I thought this might provide some info on the investments that Microsoft is still making in Integration Services. I've run into a few people in the past year who are still heavily invested in SSIS and run packages daily. SSIS seems to be a technology that isn't even close to dying for many organizations. The blog starts well, delving into the security investments with the change to the SqlClient and TLS 1.3, as well as supporting Strict Encryption. I don't know many people using this level of security, but it's good to have SSIS support stronger security. There is also an upgrade for SSIS packages targeting Fabric Data Warehouses if they modify their approach. Read the rest of An SSIS Upgrade

I ran across a post that discusses what makes you a senior engineer (via Brent Ozar). The main point of the post is that there is a core skill that separates senior engineers from others, which is reducing ambiguity. When a senior engineer gets an ill-defined (or ill-communicated) request, they can deliver a solid, or even great, result. When someone says "performance is poor," what do you do with that? Can you build a plan to identify the issues and solve them? Or do you expect the customer to explain what is slow and why it's slow? What metrics do they have showing things are slow? A senior engineer can ask questions to find the problem and then determine how to move forward. Read the rest of Where Your Value Separates You from Others

Recently, I was discussing AI with a friend, and they asked me to name a great success of using AI to build software. I've tried a few things, and I've worked with customers who are using AI tech. However, most of the things I've seen built with AI are small tasks; they're utilities or quick wins that change a minor part of the software. The items tend to be tactical and focused in a narrow band of fixes, and they might save a programmer time, but I'm not seeing large-scale team improvements in productivity. Yet. Read the rest of Your AI Successes

Security has been a constant concern for many IT professionals over the years. Many of us are trying to implement better security controls, and yet at the same time, we try to avoid anything that slows us down. Security clearly hasn't been a big enough concern, as we've had more than our share of SQL Injection issues. These often come about from poor practices, lack of education, and too many people not learning to adopt better habits across time. We've also had no shortage of lost backups, open cloud buckets, and more over the years. While security (or cybersecurity) is listed as a concern for tech management, they are quick to avoid slowing down any development or deployment of software. While it is easier to get time for patching these days, it's still not easy. There are plenty of organizations that prioritize resources spent on tasks other than patching, upgrading systems, or training developers. Read the rest of Minimally Viable Security

It's the beginning of the year, and some of you likely have today off. But plenty of you are at work, moving slowly through this Friday at the start of the year—handling busywork, catching up on maintenance you've let slide, or preparing for the tasks you know will start coming Monday. At Redgate, most engineering teams work toward a North Star goal: a high-level direction that guides your various tasks. Perhaps it's growing a customer base or achieving an overarching product specification. For example (this is completely made up), one North Star might be achieving feature parity across all platforms for SQL Compare. Read the rest of The North Star for the Year

I ran across a tweet (are they still tweets?) on X/Twitter that was titled: how to ruin yourself. It had these items, which seem to be coming from a young person. Either a student or in their first job. Stay on your phone all day. Feel sad for no clear reason. Stop eating well and ignore your studies. Sleep super late and wake up in the afternoon. Let sadness take over everything. Always look at others' lives and feel yours isn't enough. Keep blaming yourself for the past but never try to let it go. Compare your progress with people who started years before you. Get stuck imagining outcomes instead of creating them. Keep waiting for motivation instead of building discipline. What was interesting to me is I saw people doing similar things when I was younger. Either adults with careers or fellow students. I'd change "sad" to "anger", which I saw a lot in the 80s. Replace the phone with TV, as I saw lots of people start to invest a lot of time in TV with the growth of cable and 24-hour channels in the early 80s. Eating well was less of a thing, but drinking more was a thing. However, many people stagnated, or maybe ruined, themselves in similar ways. Read the rest of Finding Motivation

Most of you reading this are likely technology professionals of some sort. You might be a software developer in C# or a DBA or a manager of those teams. Maybe you're an analyst working with data and reporting. You have made this a career choice and (hopefully) are growing and learning more about your craft. I also expect that you want to continue working in the area you are now, or maybe want to move into a related area. Maybe a report writer wants to move into more warehousing/lake housing. Maybe a DBA wants to be a Reliability Engineer. You have a career and you're working in that area. Read the rest of The Side Job

The PASS Data Community Summit 2025 was held in Seattle last month, and it was an interesting event for me. I wrote a wrap-up on my blog, but a few things stood out. The event was a little smaller, with over 50% first-time attendees, but seemed to be a bit more vibrant. Perhaps people coming for the first time added something that I hadn't expected. I was a bit over-committed, so I didn't spend a lot of time in the public spaces, but things felt a little different the few times I was in the expo hall or the hallway track. I ran across a Reddit thread on the value of conferences, and it got me thinking. What is the value that you get from attending a conference (or an event). If your employer pays you might feel that you should bring some value back to them when you return. That's the premise of the thread, and I know there are plenty of people that feel that way. However. Should you value your time and effort any less? Read the rest of Your Value from a Conference

In his book, The Coming Wave, the CEO of Microsoft AI laid out the risks of AI tech bluntly. "These tools will only temporarily augment human intelligence. They will make us smarter and more efficient for a time, and will unlock enormous amounts of economic growth, but they are fundamentally labor-replacing," he wrote. Suleyman advocated for regulatory oversight and other government interventions, such as new taxes on autonomous systems and a universal basic income to prevent a socioeconomic collapse. This book was published before Suleyman joined Microsoft. Satya Nadella is more optimistic than his new deputy. In an interview at Microsoft headquarters, while sitting next to his human chief of staff, Nadella said that his Copilot assistants wouldn't replace his human assistant. As his chief of staff sat typing notes of the conversation on her tablet, Nadella acknowledged that AI will cause "hard displacement and changes in labor pools," including for Microsoft. Judson Althoff, Chief Commercial Officer, said that Nadella was pressuring his team to find ways to use AI to increase revenue without adding headcount. Read the rest of The Challenge of AI

One of the things I see software developers often talking about is how they refactor code. As they touch a class, method, etc., they may take the time to refactor the code to make it cleaner, perform better, or just add some documentation. It seems that a regular part of a software developer's job is refactoring code in the codebase. That is unless they see a "don't touch this, no idea how it works" comment. There are plenty of those, and often everyone leaves that code alone. Read the rest of Refactoring SQL Code

The GenAI boom is growing like crazy. From hype to disasters to successes to investment to the embedding of GenAI tech into lots of products, it seems no one gets away from AI. My wife, kids, friends, they all talk about AI and alternately give me stories of huge successes or epic failures. Even those who just scroll through reels aren't immune as we see amazing things, but we can't trust them because of AI. Who knows what image/video/audio was actually recorded and what was generated. Like many of you, I think AI can be amazing. Like more of you, I think it can be a really poor partner and it produces output I can't trust. I think one of the major challenges is learning to treat an AI like a colleague whose work quality is erratic. It's not that I can't work with them and use their work, but I need to test, validate, and verify the code they give me does what I need, at some acceptable quality level. Read the rest of Investing for AI

Recently I saw an article on Simple Talk, 15 Practical Tips for Securing SQL Server, and I thought that many of these are fairly simple things. Turn off unused features, disable sa, etc. These are things that a lot of people probably ensure are in their SQL Servers builds. Though, I'm sure a lot of people don't bother. Read the rest of Your Security Checkup

Imagine a perfect world? I have an AI agent that knows my business well. It's getting real time input from sales, from customers, it makes amazing decisions. We get a large order? We need to ramp up production of our widgets. We have an order pipeline of xx widgets and we know over time that yy% will close. Let's place a larger order with a supplier overseas. The next day, we have an election and tariffs are announced on imported parts. We react immediately, cancel the order, start the process to expand a local factory. We place ads to hire workers and order equipment. Things are looking good for our business and our factory will be up and running in a few months. Read the rest of How Important Are Real Time Decisions?

Over the years I've had no shortage of licensing questions for SQL Server. At times it's felt a little crazy. Look at the licensing guide. Choose EE or SE and the number of cores. Then check if you're using VMs. Oh, and consider the cloud, and which cloud you're running a workload on. It's simple right? It can seem confusing, and at times I've wished Microsoft would make it simpler. And perhaps even give us some add-ons, like adding some additional hardware capabilities (cough more RAM *cough) in SE. Read the rest of SQL Server Licensing is Simple

If you graph computer/query cost against the size of data, you can get four quadrants: small data, small compute (most CRUD app queries) small data, big compute (complex BI queries for this quarter, most reporting) big data, small compute (logs, audit data) big data, big compute (complex BI queries across all our data) Read the rest of Don't Let Corner Cases Drive Your Design

A few weeks ago, I was at the Small Data SF 2025 Conference in San Francisco. I attended the inaugural event last year and decided to go back again. It's a great chance to hear people thinking about data and its impact on the world in a different way, recognizing that building lager and larger systems isn't always possible. Or a good idea. We might find that smaller systems fit well, especially smaller datasets, which can both serve our purposes and create agility. The manifesto of the conference says that "We champion the power of Small Data and smart AI, believing that less is truly more." There's a bit more, but that's the idea. The format for the conference is a little different, with 3-5 talks in a row, all on one stage, each about 25 minutes long. These are talks with or without slides, but no live demos, just speaking and expressing a point of view. What I found fun was that each person picked their own music to play as they walked onto stage (or ran/danced in the case of Glauber from Turso). It was a bit of fun, with the DJ letting the music play as the person made their way to the front and were welcomed by the audience. I heard rock, metal, hip hop, and more. Read the rest of What's Your Theme Music?

Mary Spender is a musician in the UK who I follow and hope to see live one day. She works hard producing content about music, that business, and, of course, songs. Recently she had a little essay on Instagram where talked about creative time and focus. In it she referenced Elizabeth Gilbert saying "done is better than good." My initial reaction was "that's right." Read the rest of Done is Better than Good

Recently, I had a few questions on database modeling. One was posted in the SQL Server Central forums, and a customer asked about ERD tooling on the same day. This came shortly after Redgate acquired Vertabelo (now Redgate Data Modeler). This stood out to me as very rarely in the last few years have I found people consulting and updating a diagram while performing database development. When I started as a developer and needed to update a database, I had to first update a diagram that was stored in ErWin. We had a dedicated computer (back when we went to an office every day) where the software was run and any developer could us this to update the diagram with proposed changes. Back then, we had to get another peer to sign off on changes before making them, and the peer was supposed to go check the diagram for the change before approving it. That's only if they thought your change made sense and conformed to our standards (naming, design, etc.). Read the rest of Is Data Modeling Common?

SQL Server 2025 was released this week. The announcement came at Ignite and the PASS Data Community Summit with keynotes on Wednesday and Thursday, respectively. While there are some things to look forward to in the release (What's New) and some highlights from T-SQL Tuesday this week, it seems that this release wasn't a very exciting one. On one hand, I blame all the Microsoft Fabric focus, which seems to distract from the core product that powers the databases at many organizations. The SQL Server blog from Microsoft has had relatively few posts this year, highlighting a few things. The Fabric blog gets more posts, which is something I've seen at Database Weekly as well. As I curate the content during my week, I find a lot more Fabric-focused content than SQL Server-specific posts. That contributes to a lack of excitement for a new version of SQL Server. Read the reset of An Unexciting Exciting Release

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