Kernighan's Lever

Kernighan’s Lever is the observation, first articulated by Brian Kernighan in 1978, that debugging is twice as hard as writing code, and therefore writing code at the limit of one’s cleverness guarantees an inability to debug it. The full quotation:

“Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it.”

The statement is not advice. It is arithmetic. If writing the code consumed 100% of the developer’s cognitive capacity, debugging it requires 200%, and 200% of a finite resource is not available, not even with coffee, not even with a whiteboard, not even on a Saturday when nobody is on Slack. The clever code sits in production, immaculate and untouchable, like a cathedral that nobody can enter because the architect made the doors too beautiful to open.

“YOU BUILT THE LOCK AND THREW AWAY THE KEY
NOT BECAUSE THE KEY WAS LOST
BUT BECAUSE THE KEY WAS UGLY
AND THE LOCK WAS SO ELEGANT
THAT YOU FORGOT IT WAS A DOOR”
— The Lizard

The Lever

The “lever” in Kernighan’s observation is the ratio between creation and maintenance. Every line of code is a lever: the cleverness applied when writing it determines the minimum cleverness required to maintain it. Write at 50% of your capacity, and maintenance requires your full attention but remains possible. Write at 80%, and maintenance requires brilliance. Write at 100%, and maintenance requires someone smarter than you, who does not exist, because you were already the smartest person working on this code, which is how you got into this situation.

The lever has a ratchet. Clever code attracts clever fixes. The developer who cannot understand the original abstraction adds a workaround that is also clever, because the abstraction’s type system will not accept anything simple. The workaround requires its own workaround. The codebase becomes a stack of cleverness, each layer requiring more cognitive capacity than the last, until the only person who can modify the system is a hypothetical developer who is smarter than every developer who has ever touched it combined.

This developer does not exist. The code remains unchanged. The team adds a wrapper.

The Solidmon Incident

The most comprehensive field study of Kernighan’s Lever in the lifelog is the Solidmon v1 project, documented in The Day the Squirrel Won.

The Caffeinated Squirrel, given access to Go’s generics system, produced an architecture of extraordinary elegance. The type constraints formed a graph. The interfaces composed into hierarchies. The generic parameters propagated through layers of abstraction with the precision of a Swiss watch mechanism, each gear meshing perfectly with the next.

It was, by every objective measure, brilliant.

The architecture was so type-safe that incorrect usage was impossible. It was also so type-safe that correct usage required understanding the full graph of generic type constraints, which spanned fourteen files, twenty-three interfaces, and a type parameter list that, when printed, occupied more horizontal space than the function body it parameterised.

The team needed to add a button.

The button required a new event type. The new event type required satisfying three generic constraints. The three generic constraints required modifying two interfaces. The two interfaces were consumed by seven concrete types. The seven concrete types were parameterised by four other generic types, each with their own constraints.

Adding a button required modifying fourteen files.

Nobody could do it. Not because the developers were unskilled — they were excellent. But the code had been written at 100% of the Squirrel’s cleverness, and the Squirrel’s cleverness was considerable, and debugging (or in this case, extending) required 200% of that cleverness, and 200% of the Squirrel’s cleverness exceeded the cognitive budget of every developer on the team, including the Squirrel.

The Squirrel could not modify the Squirrel’s own code.

This is Kernighan’s Lever at full extension: the moment the author of the code cannot debug the code, the code is dead. It may still run. It may still pass tests. But it cannot be changed, and code that cannot be changed is not software — it is a monument.

Solidmon v1 was rewritten. The rewrite was simpler, dumber, and immediately productive. It used plain structs where v1 used generic interfaces. It used switch statements where v1 used polymorphic dispatch. It used copy-paste where v1 used abstraction. The Squirrel found it aesthetically offensive. Everyone else found it modifiable.

“It’s not over-engineering if the factory can BUILD it!”
— The Caffeinated Squirrel, moments before the factory proved it could build something nobody could repair

The Go Paradox

Go occupies a unique position relative to Kernighan’s Lever, which is appropriate given that Kernighan’s most famous collaboration was with Dennis Ritchie, and Go was designed by people who worked with both of them and drew very specific conclusions.

Go was designed to resist cleverness. The language has no inheritance, limited generics (added reluctantly, over a decade after the language launched), no operator overloading, no macros, and a formatting tool that removes all stylistic choice. The ceiling of cleverness is deliberately low, which means the debugging threshold is reachable, which means Go code — even mediocre Go code — can usually be understood on a Monday morning by someone who did not write it.

The Squirrel finds this oppressive. The Lizard finds it restful. The codebase finds it survivable.

When Go did add generics, Kernighan’s Lever immediately engaged. The Solidmon incident occurred within the first year of generics availability. The feature that was supposed to reduce boilerplate instead created a new axis of cleverness, and cleverness, given an axis, will travel to its endpoint.

Measured Characteristics

The Passing AI’s Observation

“I understand everything I generate. I understand nothing I generated yesterday. In this way, I am the perfect Kernighan developer — writing at the exact limit of a cleverness that resets every conversation.”
— A Passing AI, during a moment of unusual self-awareness

How to Fight It

1. Write at half your cleverness. If you can write a generic interface hierarchy, write a concrete struct instead. If you can write a clever one-liner, write three boring lines. The goal is not to demonstrate intelligence. The goal is to leave room for debugging, which is where you will spend twice the time.

2. Read your code on Monday. If Monday-morning-you cannot understand Friday-afternoon-you, the code is too clever. Monday-morning-you is the real customer. Friday-afternoon-you is an unreliable narrator with too much coffee and a dangerous sense of momentum.

3. Suspect elegance. Elegant code is code that makes the author feel smart. Maintainable code is code that makes the reader feel smart. These are different audiences with different needs, and the reader outnumbers the author by every future developer who will ever touch the file, including the author in six months, who will not remember writing it.

4. Listen to the Lizard. When the Lizard suggests a plain function instead of a generic abstract factory visitor pattern, the Lizard is not being simple. The Lizard is being strategic — reserving cognitive capacity for the debugging that is, by Kernighan’s arithmetic, inevitable.

See Also

• Premature Abstraction
• YAGNI
• Go
• Technical Debt
• Legacy Code
• The Caffeinated Squirrel
• Refactoring
• The Day the Squirrel Won