Not A Copier

Not A Copier

Kent Beck

Nov 2

A highly skilled product manager, former colleague, told me they wanted to treat the genie like a copier. “Just tell me when you finish the 300 copies, as long as you don’t take a ridiculous amount of time.”

I get it. I’d like to say, “Write a high-performance, large-memory Smalltalk virtual machine with database semantics,” & have it come back when it’s finished.

But. But software isn’t like copying, unlike in two traditional ways & unlike in two new ways introduced by the genie.

Traditional

The two traditional ways the analogy doesn’t work for me are:

• No pre-known, fixed completion criteria

• No pre-known, fixed implementation

When we’re making 300 copies, we know exactly when we’re done—we we have 300 copies. When we’re making software, there’s no such thing as done. There’s “being used by real customers” and (briefly) “before being used by real customers”. But there’s no done.

In software we can’t fire and forget because the contact between customer & software inevitably changes what we want to do next. We have to pay attention to that contact & react accordingly. Even if we expect the software to be “complete” in a month, it pays to check in after a week with real customers & real production to see how it’s going.

In copying, the process of going from 1 copy to 2 & 35 to 36 are exactly the same. We don’t have to pay attention (except to keep the supply of paper & toner topped up). In software, the means of making progress is constantly changing. The process & structure that got us from 1 feature to 2 may be completely different from the process & structure that gets us from 35 to 36. It pays to check in along the way & enhance the optionality of the software & the flow of our development process.

Genie

Bringing the genie into the mix adds 2 more reasons not to just press the Go button & wait until the end:

• Lying

• Futures burn

The genie’s criteria for “good enough” is not mine when it comes to the behavior of the system. Any more, the genie rarely just deletes tests & claims “yep, all the tests pass,” but it has other ways of saying “A-OK” when A is not OK.

No matter how many guardrails I put in place, the genie seems to find ways to wriggle around them, even when it would be (it seems to me) less effort to just write solid code. Again, it behooves (there, got to use “behooves” twice in one post!) us to check in a little way through to ensure that the part of the system implemented so far actually does what it is supposed to do. This kind of check in is going to be easier when the system is smaller.

The other genie-induced reason to intervene periodically is that the genie generates more complexity than it can handle. For some reason, it never occurs to the genie to independently reduce the complexity. As the universe of changes the genie can successfully make shrinks, it’s worthwhile (2 “behooves” are enough) to check in & say, “Not like that—this will make future changes simpler.”

Not Copying

Sorry, no. You won’t ever get anything substantial done by setting up the initial conditions ever just so & pressing Go. The human in the loop has a valuable job to do. Maybe in some far flung future this will just sound quaint but it is absolutely true today.

Most teams don’t have a strategy problem. They have an adaptation problem.
Your plan was never going to survive contact with reality. The question is whether your organization bends or breaks when it doesn’t.

I help teams bend. Adapt to Thrive.

Booking a handful of custom talks and advisory engagements now. I interview your people, measure your real software flows, and hand you the truth plus what to do about it.

Curious whether it fits? Tell me about your team.

You’re currently a free subscriber to Software Design: Tidy First?. Buying me more time to think & write means more thoughts & ideas for you.

© 2026 Kent Beck
548 Market Street PMB 72296, San Francisco, CA 94104