The Shark Stops Evolving 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. The recognizably modern great white has held roughly the same body plan for millions of years — a design good enough that its environment never gave it a reason to become something else.

That's the pattern I want to talk about: a successful design that keeps working because nothing is asking it to change.

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. Continuous improvement can quietly change from a useful discipline into an unquestioned mandate — the assumption that every working system must have another sprint, another refinement, another reason for us to remain involved.

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

The disclosure system

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.

A few years later, a different project brought me back in touch with the same customer. Before we got into it, I asked how the disclosure system was holding up.

Fine, they said. Nobody touches it. It still works.

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.

Why we keep touching things

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.

Megalodon

Megalodon was 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, the 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 design can be extraordinarily successful for a long time and still fail when the environment around it changes. 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've built goes quiet — no bug reports, no change requests, nobody asking for anything new — the real question isn't whether it's stable. It's whether it's stable because it solved the problem, or stable because nobody's checked. An uptime dashboard can't tell the difference. Neither can a customer who hasn't called in years. A team can be quiet because everyone understands the job, or because everyone's given up — same surface, different reality underneath.

My disclosure application ran untouched for years, and that's a fine outcome — but the lesson isn't "never touch working software." Intervention should follow evidence, not anxiety.

Stop changing what doesn't need changing. Never stop noticing.

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.