The slow query is rarely the problem
When a business system slows down, someone finds the worst query and adds an index. It helps for a month. What is actually going on in long-lived SQL Server systems, and the one session that finds most of it.
What we learn taking ownership of established applications — written for the people who have to maintain the thing afterwards.
When a business system slows down, someone finds the worst query and adds an index. It helps for a month. What is actually going on in long-lived SQL Server systems, and the one session that finds most of it.
The previous team has gone, the code is somewhere between 40 and 80 percent done, and nobody is sure which. What the first month should establish, and why the first release should change nothing visible.
Payment gateways are straightforward to integrate and difficult to operate. The problems appear months later, and almost none of them are in the happy path.
The useful question is not where you can put AI. It is which parts of a job people are still doing by hand because the software cannot help them yet.
Field staff want an app; the rebuild quote is frightening. You usually do not need one: your existing system already knows everything the app needs.
The API layer is the hinge of most modernization work, and where teams most often start in the wrong place: exposing the database instead of the business.
In many long-lived business systems the rules that matter most are not in the C# but in T-SQL nobody will touch. How we map them without breaking anything.
Before changing anything in an application we did not write, we spend two weeks reading it. What we are actually looking for, and why the order matters.
Let's work together
Most of what we write about started as somebody's difficult Monday morning. If one of these sounds familiar, tell us about it.