Both Teams Were Right. The Database Still Crashed.
The most expensive problems I have been called into did not live inside either system. They lived in the space where two correct systems met. Here is what I look at first, and why I stopped asking who was wrong.
A Microsoft SQL Server database was crashing. Not politely, and not with anything you could put in a ticket. It would fall over, come back, and leave behind an error log that described the symptom and nothing else.
Two teams had already looked at it by the time I got there. The database team went through the database and found a database that was fine. Configuration, indexes, query plans, all of it defensible. The virtualization team went through the virtualization layer and found virtualization that was fine. Resources allocated, host healthy, nothing overcommitted.
So the two teams did what two teams do. Each one pointed at the other, politely at first.
Here is the part that took me a while to appreciate: they were both telling the truth. There was no database problem. There was no virtualization problem. The database was larger than anyone recommends putting on virtualized storage, and the crash lived in what happened when that specific workload met that specific storage layer. An I/O bottleneck that neither team could see from inside their own system, because from inside either system there was nothing to see. The answer was that this database needed to go back on physical hardware, and getting there meant proving something uncomfortable: two individually correct answers had combined into one broken whole.
Nobody had been looking at the boundary. Everybody had been looking at their own side of it.
The pattern has a name now
I have been doing this for thirty years, and that shape keeps coming back. Two systems, two teams, two sets of assumptions, each one internally consistent and defensible, colliding at an interface nobody owns. The failure has no home. It belongs to the relationship.
I finally started calling this what it is. I solve problems at the seams.
The biggest opportunities are not inside systems. They are at the seams between them.
The default framing of a technical problem is a choice between two losses. One system gets replaced. One team changes its process. One side eats the limitations of the other and pays for it every day afterward in manual work nobody put on a roadmap. I have watched a lot of money get spent that way, and most of the time it was avoidable.
The alternative is to treat the interface as the thing you are designing. Not a gap between the real work, the actual work. Can we fix the seam instead of forcing either side to change?
Sometimes the answer is no. But it is asked far less often than it should be, and when it works, it is dramatically cheaper than the alternative.
Thirty-seven columns into thirty-six
A designer once handed me a layout built on a 37-column grid. The system it had to be implemented in expected 36.
The obvious move is to send it back. The design is wrong, technically, in the sense that it does not match the target. Reject it, explain the constraint, wait a week, get a redesign, hope nothing was lost in translation. Every part of that is defensible and every part of it is waste.
What I did instead was write an SCSS function that translated a 37-column design into a 36-column implementation grid mathematically. It took less time than the meeting about the redesign would have. The designer kept the composition they had reasoned their way to. The build system kept the grid it was written against. Nobody redid anything, and the incompatibility stopped existing.
That is the whole move, and it is not a clever one. It is just a different question. Not which of these two is wrong but what would have to be true for both of them to be right.
A prototype that could not run on the tablet it was for
Same shape, different scale. Microsoft had a prototype, heavy on CSS animation, built and tuned against WebKit. It needed to run on a new Surface tablet, in Internet Explorer, which at that point did not have the media query support the whole thing was built on.
Two real options were on the table. Redesign the prototype for the browser, which meant rebuilding the part of it that made it worth showing. Or abandon the platform, which was the entire point of the exercise.
The third option was a script that detected the screen dimensions and applied a universal CSS zoom adjustment, so the layout resolved correctly without the prototype knowing anything had happened. The design intent survived. The hardware requirement was met. The compatibility gap did not get solved so much as it got absorbed, which from the outside looks identical and costs a fraction as much.
None of these are impressive pieces of engineering. That is sort of the point. Seam work is rarely hard in the way people expect hard problems to be hard. It is hard in that almost nobody is looking there.
What I ask first now
When something is broken and the people responsible for each half have already cleared their half, I stop debugging components and start debugging the relationship:
- Name both sides. Which two systems, teams, incentives, or assumptions are actually colliding? If you cannot name them precisely, you are not working the real problem yet.
- Assume both sides may be right. Follow that all the way through. It is usually the version nobody has worked, because it is the version with no one to blame.
- Find the translation burden. Somebody is compensating for the mismatch by hand right now, probably in a spreadsheet, probably without complaining. That manual work is the receipt. It tells you exactly where the seam is and roughly what it costs.
- Name the kind of failure. Format, timing, scale, ownership, terminology, workflow, incentives, compatibility, expectations. Being specific here is most of the work.
- Ask what could absorb it. Software, process, automation, policy, or occasionally just two people agreeing on a word.
- Check that both sides survive. If your fix degrades what either side already does well, you did not build a seam. You built a tax and named it a solution.
The one I care about most: never make humans do what software can do. If a mismatch can be absorbed by a translation layer, it should be, because otherwise it gets absorbed by a person doing tedious reconciliation forever, and that cost never shows up anywhere anyone is looking.
This is getting more common, not less
Every trend I can point at right now is producing more seams. More systems that have to talk to each other, more vendors, more integration points, more organizations cooperating without merging. AI in particular is an enormous new seam, and most of the trouble I am asked to look at is not inside the model. It is between the model and the humans expected to use its output, or between what a tool can generate and what an organization can actually review and be responsible for. Both sides working as designed. The failure in between.
If you are debugging inside the boxes, you will find that both boxes are fine. They usually are.
The best seam disappears
The measure of good seam work is that people stop noticing there was ever an incompatibility. Nobody praises the SCSS function. Nobody writes a case study about a zoom adjustment. The database that stopped crashing does not generate a follow-up meeting.
That is what makes it hard to sell and easy to underrate, and it is still the highest-leverage work I know how to do. The goal is never to make either side become the other. It is to build the seam that lets both sides keep being what they already are.
I wrote up the longer version of how I think about this, including the full diagnostic, over here. If you have got two things that will not line up and everyone involved has already proven their half works, that is my favorite kind of email.