The Craft of Software: A Philosophy of Quality That Ships

---

There's a tension I've watched play out on every team I've led. On one side: ship fast, move on, perfect is the enemy of good. On the other: a quiet unease from the best engineers that we're building something we'll be ashamed of in a year. Both sides think they're right. Both sides are half right. And the argument never resolves because nobody's defined the word at the center of it: quality.

Most "quality" talk is useless because it's vague. It gets used to mean "slow and expensive" by the people who want to ship, and "the thing we never have time for" by the people who care. Neither is what craft actually means. Craft is not gold-plating, and it is not the opposite of velocity. Craft is building things that hold up — that age well, stay maintainable, and don't quietly rot — while still shipping. Speed and quality aren't opposites; cheap-and-fast and built-to-last are different bets, and the craftsman knows which one each situation calls for.

I think about software quality through an unusual lens — watches, luxury goods, things made to last decades — because those fields have spent centuries answering questions our industry is still confused about. This is the map of that thinking, and the home base for the essays that explore each piece. If you take one idea from it: craft is a standard you hold, not a phase you schedule.

Where craft comes from: lessons outside software

The most useful ideas about software quality, I've found, come from outside software — from disciplines that have a longer relationship with "made to last."

• Watchmaking taught me that quality is the accumulation of small disciplines, not a final polish. A mechanical watch keeps time for decades because every component meets tolerance, not because someone buffed it at the end. → What Swiss Watchmaking Taught Me About Software Quality

• Luxury constraints taught me that limits create quality, not the absence of them. Hermès makes fewer things, slowly, and that constraint is the point. → What Hermès Can Teach Software Teams About Constraints, Craft, and Patience

• Patina taught me that age isn't always decay. Some systems, like some objects, earn character as they age — and some are just old. Knowing the difference is judgment. → Patina in Code: When Age Adds Character (vs When It's Just Old)

• Vintage tech taught me that "newer" and "better" aren't synonyms, and that the rush to ship sometimes discards things worth keeping. → Vintage Tech: What We Lost in the Rush to Ship Fast

The throughline: every mature craft has already worked out that durability, restraint, and long-term thinking are what separate the disposable from the lasting. Software keeps relearning it the hard way.

Why quality is hard even when we want it

Wanting quality isn't enough — there are structural and psychological reasons good engineers ship things they're not proud of.

• The psychology of corner-cutting. Even engineers who care cut corners, predictably, under specific pressures. Understanding why is how you build systems that make the quality path the easy path. → The Psychology of Quality: Why Good Engineers Still Cut Corners

• The hidden cost of cheap. "We'll fix it later" is a loan, and maintenance is the interest. Cheap-to-build is often expensive-to-own, and that cost is invisible until it isn't. → Maintenance as Luxury: The Hidden Cost of 'Cheap' in Software

• The hype cycle. Chasing every new framework feels like progress and is often the enemy of craft — you never get good at anything because you never stay. → Sneaker Drops and Software Hype: How to Stop Chasing the Next Big Thing

The pattern: quality fails not because people don't care, but because the incentives, the psychology, and the noise all push the other way. Craft is partly about designing your environment so the right thing is also the easy thing.

The discipline of finishing and focusing

Craft shows up most in two unglamorous places: finishing what you start, and resisting the urge to add.

• The art of finishing. Projects die at 90% because the last 10% — the edges, the polish, the cleanup — is the hardest and least rewarded. Shipping complete work is a craft skill. → The Art of Finishing: Why Projects Die at 90%

• The minimalist stack. Mastering fewer tools beats chasing every new one. Depth compounds; breadth scatters. Restraint is a craft discipline, not a limitation. → The Minimalist Developer Stack: Why Mastering Fewer Tools Beats Chasing Every New Framework

Craft in the age of AI

This is the newest and most urgent question, and it deserves its own deep treatment. When AI can generate plausible code instantly, does craft still matter — or is taste a relic? My argument is that craft matters more, not less: when production is free, the scarce, valuable thing is the judgment to tell good from plausible, and the taste to shape generated output into something that lasts. → Does AI Kill Craft? Taste, Judgment, and Quality in the Age of Generated Code

This connects craft to the core of the engineering shift I write about elsewhere — that judgment is the new bottleneck and that senior engineers leverage AI precisely through the taste AI doesn't have.

How craft fits with architecture and leadership

Craft isn't a separate pillar floating off on its own — it's the standard you hold while doing the other work. Architecture is about which decisions to make; leadership is about getting a team to make them well; craft is the bar for how well anything gets executed. A beautiful architecture built without craft rots; a well-led team without a craft standard ships fast and accumulates shame. The three reinforce each other:

• Architecture decides the shape.
• Leadership aligns the people.
• Craft sets the standard the shape and the people are held to.

The best engineers and teams I've known hold all three at once — and refuse the false choice between shipping and caring.

Key takeaways

• Craft is building things that hold up while still shipping — not gold-plating, not slowness, not the enemy of velocity. Cheap-fast and built-to-last are different bets, and craft is knowing which one a situation calls for.

• The best ideas about quality come from outside software — watchmaking (quality is accumulated discipline), luxury (constraints create quality), patina (age can add character or just be old), vintage tech (newer isn't always better).

• Quality fails for structural reasons, not just lack of care. Corner-cutting is predictable under pressure, "cheap" hides its maintenance cost, and hype pulls you off mastery. Craft means designing your environment so the right thing is the easy thing.

• Finishing and focusing are core craft disciplines. Projects die at 90% because the last 10% is hardest; mastering fewer tools beats chasing every new one. Restraint and completion are skills.

• AI makes craft more important, not less. When code production is free, the scarce thing is the judgment and taste to tell good from plausible and shape output into something durable.

Your next step

Pick the piece of this map that's most alive on your team right now — maybe it's the 90% projects that never quite ship, maybe it's the tool-of-the-month churn, maybe it's the unease about AI and quality — and read the essay it links to. Then ask the question craft always comes back to: are we building something we'll be glad we built in two years, or something we'll be quietly fixing? That question, held honestly and often, is most of what craftsmanship actually is.

Frequently asked questions

What does software craftsmanship actually mean?

Software craftsmanship is the discipline of building software that holds up over time — that ages well, stays maintainable, and doesn't quietly rot — while still shipping. It is not gold-plating, not slowness, and not the opposite of velocity. Cheap-and-fast and built-to-last are different bets suited to different situations, and craftsmanship is the judgment to know which one a given situation calls for, plus the standard you hold while executing. It's a standard you maintain, not a phase you schedule after the "real" work.

Is software quality the enemy of shipping fast?

No. The framing of quality versus speed is a false choice. Craft is about building things that hold up while shipping, not about being slow. Some situations genuinely call for cheap-and-fast (a throwaway prototype, a bet you may discard), and a craftsman recognizes those and doesn't over-build. The waste comes from treating quality as a separate, schedulable phase rather than a standard held during execution — and from cutting corners whose maintenance cost later exceeds the time they saved.

Why do good engineers still cut corners?

Because corner-cutting is driven by predictable structural and psychological pressures, not by a lack of caring. Deadlines, invisible long-term costs, misaligned incentives, and the constant noise of new tools all push against quality even for engineers who value it. The practical response isn't exhortation to "care more" — it's designing the environment so the quality path is also the easy path, making good defaults, guardrails, and finishing the path of least resistance.

Does AI make software craftsmanship obsolete?

The opposite — craft matters more when AI can generate plausible code instantly. When production becomes nearly free, the scarce and valuable skills are the judgment to distinguish genuinely good code from merely plausible code, and the taste to shape generated output into something maintainable and durable. AI removes much of the typing, not the discernment; an engineer without craft will ship confident-looking generated code that rots, while one with craft uses AI as a tool and holds the same standard they always did.

How does craft relate to architecture and technical leadership?

They are three reinforcing dimensions of good engineering, not separate concerns. Architecture decides the shape of the system, leadership aligns the people to build it well, and craft sets the standard of execution that both are held to. A strong architecture built without craft still rots, and a well-led team without a craft standard ships quickly but accumulates work it's ashamed of. The best engineers and teams hold all three at once and refuse the false choice between shipping and caring.