The Shark Stops When It's Done

The great white is often described as a masterpiece of evolution. Millions of years of refinement, generation after generation, sharper and deadlier — the perfect killing machine, endlessly honed.

That description points to the wrong lesson.

The myth

The great white hasn't been changing much at all. Not because it's primitive. Not because it's stuck. Sharks carry some of the slowest mutation rates of any vertebrates alive, and the recognizably modern great white has held roughly the same shape for millions of years.

That's the pattern I want to talk about: a successful design that keeps working because its environment hasn't given it a reason to become something else.

Adaptation is a response, not a habit

Evolution doesn't run on ambition. A species doesn't change because change looks virtuous, or because standing still feels risky, or because everyone else seems to be moving.

It changes when the environment stops rewarding what it already is.

This cuts against almost everything business culture inherited from the last thirty years. If it ain't broke, break it. Disrupt yourself before someone else does. Agile as a permanent condition instead of a method for getting somewhere. Continuous improvement, taken not as a tool but as a mandate — the assumption that a system is never actually finished, that there's always another sprint, another refinement, another reason to still be in the room.

I don't think that's true. I've built enough software to know it isn't.

Several years ago I built an application to manage an annual disclosure process for a large oil and gas company — once a year, it emailed every employee and asked them to report conflicts of interest and stockholdings complicated enough to need a second look. The customer was happy with it, and I didn't hear from them again about it. Then, a few years later, I got a call — not about the disclosure app. A different problem, a different project. Before we got into it, I asked how the disclosure system was holding up. Fine, they said. Nobody touches it. It had been running for years, untouched, still doing exactly the job it was built to do.

That's not stagnation. That's the product having solved the problem it was built to solve — and everyone involved having the discipline to quit messing with it once it did.

The instinct to keep touching something that's working isn't really about the product. It's about the builder. It's easier to justify staying in the room than to admit the job is done.

I've spent a career in a profession that rewards people for building things, improving things, attending meetings about things, producing backlogs for things, maintaining organizational relevance around things. Nobody gets promoted for a system they left alone. Nobody puts "resisted the urge to refactor a working application" on a resume. Software rewards visible motion — commits, sprints, roadmap slides — far more readily than it rewards the quieter discipline of deciding there's nothing left to do. Of course we struggle to say a thing is done. Saying so means admitting the job that justified the meeting is finished.

A good developer's job isn't to create a situation that requires their ongoing presence. It's to solve the actual problem and get out of the way.

The great white doesn't stay in the water column proving it's still trying. It moves when the ocean gives it a reason to.

The part that should worry you

From the outside, a species that hasn't changed because nothing is asking it to looks identical to one that's simply stagnant and hasn't been punished for it yet. You can't tell the difference by looking at the animal. You can only tell by watching whether the environment underneath it is still the one it was built for.

Something like that happened to megalodon. Dominant, enormous, about as close to unchallenged as a predator gets. Paleontologists still argue over exactly what tipped it — competition from great whites, cooling waters, prey moving out of range, physiological costs of its own size, probably some combination — but the shape of the story holds regardless of which cause carried the most weight: its environment shifted, and it didn't. A successful design can survive for ages and still turn out to be poorly matched to a world that has since moved on.

The great white is still here. Megalodon isn't.

Activity versus attention

This isn't really an argument for leaving things alone. It's an argument for the difference between activity and attention.

When something I built has gone quiet — no bug reports, no change requests, nobody asking for anything new — the real question is whether it's stable because it solved the problem, or stable because nobody's checked.

The two look identical from the outside. An uptime dashboard doesn't know the difference. Neither does a customer who hasn't called in years. A process can be quiet because it works. A team can be quiet because everybody understands what to do, or because everybody's given up. Those states look surprisingly similar from across the room. The only way to actually tell is to go looking: is the environment this thing was built for still the environment it's sitting in?

My disclosure application worked for years without intervention, and that's a fine outcome — but the lesson isn't "never touch working software." The lesson is that intervention should follow evidence, not anxiety. Stop changing what doesn't need changing. Never stop noticing.

Leaving a solved problem alone is not neglect. Neglect is leaving it alone after the problem has changed. The responsibility was never continuous improvement. It's continuous attention.

Explore More

• Turtling: When a Team Stops Looking for the Door — the same "activity versus attention" question, aimed at teams that have quietly stopped looking for a way through a blocker rather than systems that have quietly stopped needing one.
• Every Arm Is Still Searching: The Octopus Model of Agency — the other half of this argument: knowing when to keep searching, versus knowing when the search is over.
• The Beaver Builds a Pond — a beaver reads the stream and builds only what it needs; the same discipline applies to deciding a system needs nothing more.
• The Dependencies I Never Upgraded — on judgment, not just curiosity, as the thing that makes a decision last.