Shawn Seymour
I think one of the clearest signals of what has gone wrong in software culture is this: we do not admire quality the way we should.
We admire speed. We admire output, momentum, scale, leverage, visibility, titles, compensation, and whatever new tool promises to make ten people look like fifty.
We admire shipping. We admire acceleration. We admire being current.
What we admire a lot less is care.
Not perfectionism. Not academic purity. Not the fantasy that every internal tool should be handcrafted like a luxury product.
I mean care in the more serious sense: judgment, restraint, coherence, durability, pride in the work. Software that feels considered. Systems that make sense. Products that have a point of view. Decisions made by people trying to build something solid instead of merely getting through the quarter.
The problem is not that people openly reject quality. The problem is that modern software culture rewards the signals of progress more consistently than the substance of it.
That used to feel closer to the center of the work. Now it often feels optional.
And I think that explains a lot about why so much modern software feels bloated, shallow, and forgettable.
A lot of teams are not moving fast. They are moving in circles.
This is not an argument against speed
To be clear, this is not an argument against speed.
Speed matters. Markets move. Competitors move. Deadlines are real. Teams have constraints. Most engineers are not operating in some ideal environment with infinite time, clean systems, and no tradeoffs.
Organizations care about speed because speed matters.
But speed without standards is usually just borrowed time.
If we have to rebuild it every two years, what are we really doing?
At some point, “moving fast” turns into borrowing against the future with interest. At some point, pragmatism becomes a euphemism for waste. At some point, speed stops being speed because half the organization is spending its time working around the consequences of yesterday’s shortcuts.
Real speed compounds. Fake speed creates cleanup.
Quality matters because the future will not look like the plan. Requirements will change. The business will change. The product will change. A good foundation does not resist that reality; it absorbs it.
That is what good boundaries, sound abstractions, and clear system design are for. They make change cheaper when change inevitably comes.
That is the part too many teams gloss over.
The industry rewards what it can count
Modern software culture is extremely good at rewarding what is visible.
Features shipped are visible. Tickets closed are visible. Deadlines hit are visible. Launches, metrics, dashboards, org charts, promotions, comp bands, adoption graphs, roadmaps — all visible. All easy to point at. All easy to bring into a meeting and convert into a story about progress.
Quality is different.
Quality is often quiet. A good API does not announce itself. A clean system mostly disappears. Good naming does not get applause. Clear boundaries do not make for a dramatic quarterly update. Restraint is hard to screenshot. Simplicity rarely looks heroic from the outside.
And because quality is harder to count, it becomes easier to under-defend.
That is one of the core problems: we have built cultures that are very good at measuring activity and much worse at protecting standards.
A culture reveals itself by what it is willing to let slide.
I think we have let too much slide.
Standards do not defend themselves
Teams learn what matters from what gets rewarded, what gets questioned, and what gets waved through.
If every conversation is about dates, staffing, delivery, and visible output, quality starts to feel optional. If nobody asks whether the system will still make sense in a year, whether the boundaries are clean, whether complexity is compounding, or whether the product is becoming easier or harder to evolve, the work drifts.
Standards are not what you write down, they are what you defend under pressure.
That applies to leaders, but it also applies to the rest of us.
You do not need to control the whole organization to raise the bar. You can ask better questions. You can push for cleaner boundaries. You can simplify instead of adding. You can challenge complexity that does not need to exist. You can refuse to call something “done” just because it technically shipped.
Culture is shaped at the organizational level, but it is reinforced in everyday decisions. A team does not become high quality by accident. People decide, repeatedly, that the bar still matters.
Mediocrity got rebranded as pragmatism
The problem is not that bad software exists. Bad software has always existed.
The real problem is that many teams no longer seem embarrassed by mediocrity.
The bar drifts downward. Everyone adjusts. Then the whole thing gets rebranded as pragmatism.
A lot of what gets called pragmatism is really just lowered standards with better branding.
You can see it everywhere. Products with more features and less clarity. Interfaces that technically work but feel like nobody is really steering. Systems built from a stack of local optimizations with no unifying logic. Codebases that move quickly in demos and decay slowly in real life. Documentation written to satisfy process instead of helping an actual human being.
And because a lot of this still “works” in the short term, it survives.
That is what makes low quality dangerous. The worst version of it is not dramatic. It is tolerable. It is mergeable. It is shippable. It is “good enough” to avoid confrontation.
Then one day the system is exhausting, the product feels directionless, simple things are weirdly hard, and everybody acts like this happened naturally.
It did not happen naturally. It happened one tolerated compromise at a time.
Cheap now, expensive forever
That is the part I wish more organizations took seriously:
Low quality is cheap up front and expensive forever.
The bill always shows up. Maybe not this sprint. Maybe not this year. But it shows up.
It shows up as maintenance drag. As brittle systems nobody wants to touch. As onboarding that feels like archaeology. As teams that claim to move fast while spending most of their energy managing the consequences of old decisions. As products that become noisy, bloated, and directionless because nobody protected the core shape of the thing.
You can see this in systems that are supposedly “easy to change” until every change requires tribal knowledge, every workflow has exceptions, and no one can clearly explain where the real source of truth lives. The code exists. The features exist. The roadmap exists. But the system has stopped making sense.
That is not scale. That is accumulated confusion.
And eventually, it shows up in the rebuild.
That is the cycle I keep coming back to. Everyone celebrates how quickly something shipped, then two years later the same organization is planning a rewrite, a replatform, a redesign, or a major simplification effort because the foundation was weak, the system got messy, and the shortcuts finally came due.
If we are rebuilding the same thing every two years because nobody cared enough to make it durable, that is not evidence of speed. That is evidence of waste.
Some call that velocity. A lot of it is just cleaning up yesterday’s shortcuts.
AI is accelerating the problem
AI did not create this problem, but it is accelerating it.
Code is cheaper to produce now. Generation is easier. More teams can create more output faster than ever before. That part is real, and pretending otherwise is not serious.
But making code cheaper does not make judgment cheaper. It does not make taste cheaper. It does not make product sense, architecture sense, or editorial discipline more automatic.
If anything, those things matter more now.
The real gap is no longer “can we generate something?” The real gap is “can we tell what should stay, what should go, what should be reworked, and what should never have been added in the first place?”
Anyone can generate. Fewer people can discern.
That gap is where quality lives.
And that is why so much AI-assisted output feels simultaneously impressive and unfinished. The speed is there. The volume is there. The surface area is there. What is often missing is the discipline to refine, simplify, remove, and shape.
AI makes generation cheaper. It does not make judgment, editing, or restraint automatic.
There is an even more dangerous version of this problem: people using AI to accelerate work they do not understand well enough to evaluate.
AI is extremely good at producing plausible artifacts. It can give you code, abstractions, architecture, copy, tests, diagrams, and momentum. What it cannot give you is ownership of the problem. It cannot tell you what the business actually needs, which constraints are real, which invariants matter, which edge cases will hurt you later, or which simplifications will hold up under change.
If you do not understand your domain, AI will not rescue you. It will help you produce a faster, more polished version of your misunderstanding.
That is not a tooling problem. That is a standards problem.
There is another pattern emerging now too: rewrites are starting to feel deceptively cheap.
With the right model and enough context, teams can regenerate large parts of a system faster than ever. That creates a dangerous illusion: that because rewriting is easier, building something durable must be easier too.
It is not.
If the standards are weak, the rewrite does not solve the underlying problem. It just produces a cleaner-looking version of the same instability. New code is not the same thing as sound code. Modern syntax is not the same thing as durable design. And AI-generated momentum is not the same thing as a system that will still be understandable and easy to change two years from now.
A rewrite without standards is just a more efficient way to go in circles.
At the same time, if a rewrite really is necessary, this is exactly when standards matter.
Now is the time to define the boundaries, simplify the abstractions, clean up the product shape, and make ease of change a real requirement instead of a vague hope. Now is the time to use AI well — not just to generate faster, but to evaluate tradeoffs, challenge complexity, remove noise, and set the system up to last.
If a rewrite is happening anyway, it should buy you durability. It should buy you clarity. It should buy you a better foundation than the one you are replacing.
The compounding effect of standards
This is why I think the conversation is bigger than code.
Standards compound, just like shortcuts do.
Once a team gets too comfortable hand-waving quality away in the name of speed, process, alignment, or pragmatism, it spreads. Thinking gets sloppier. Product decisions get sloppier. Communication gets sloppier.
The language improves while the work degrades.
You become what you tolerate. Organizations do too.
I do not think the goal is perfection. I do not think every system needs to be elegant. I do not think every team can afford to operate like a design studio.
But I do think there is a meaningful difference between shipping something and building something well.
The best organizations know that quality is not just polish layered on at the end. It is in the decisions. The boundaries. The defaults. The naming. The product shape. The restraint. The willingness to remove instead of endlessly add.
Quality is rarely one dramatic choice. It is usually the accumulation of many disciplined ones.
What are we actually building?
If the whole game is shipping faster, patching around the mess, rebuilding it two years later, and calling that progress, then what are we actually building?
More software? Sure.
Better software? Not necessarily.
Better organizations? Probably not.
Better standards? Definitely not.
I still think quality is one of the few things that compounds in the right direction. It reduces friction. It extends the life of systems. It sharpens products. It helps teams move with less drag. It creates foundations people can actually build on.
In other words: quality is not the enemy of speed. It is how real speed lasts.
And in an environment obsessed with acceleration, it may be one of the last real differentiators left.
Because almost everyone can generate now.
Far fewer can still judge.
Far fewer can still edit.
Far fewer can still protect the shape of the thing.
That is why this matters.
And that is why it feels like nobody cares about quality anymore.