Monday, 9:12. Dr Brambilla leans on your desk with the smile of a man who is about to ask for something small.
“Listen, can we put the customer’s phone number on the invoice PDF? Accounting wants to call them when they don’t pay.”
You don’t even look up. “Sure. It’s easy. Five minutes.”
And somewhere inside your head, behind your eyes, something large and black-and-white slowly opens one eye.
🐄 Moo. Did you just say “five minutes”? Before opening the code? Oh, this is going to be fun.
9:13 · The cow does the maths
Every programmer has one: a little voice that knows better. Yours happens to be a cow, and she has a rule. It has no known author: programmers pass it down to each other like a family recipe, and it belongs to the same family as Murphy’s law (“anything that can go wrong will go wrong”, born at an American air base in the late 1940s). The rule says: take the estimate, multiply it by two, and move to the next unit of measure.
🐄 Five minutes, times two, next unit: ten hours. I’ll be generous and not apply it twice. Yet.
9:40 · Where does the phone number live?
You open the invoice table. Customer name, VAT number, address. No phone. The phone numbers live in the CRM, another system, copied over every night by a sync script nobody has opened since it was written.
And in the CRM, some customers have three phone numbers. Some have none. One has, in the phone field, “call Gianni after 3pm”.
🐄 Which number goes on the invoice? Don’t look at me, I’m a cow. Go and ask Brambilla. Ha. He’ll say “the right one”.
He says “the right one”.
Douglas Hofstadter wrote it down in 1979, in Gödel, Escher, Bach: it always takes longer than you expect, even when you take into account Hofstadter’s Law. It’s the only law that already knows you’ve read it.
11:30 · The file nobody touches
The PDF is produced by a library that was old when it was installed. The template is in a file that opens like this:
# invoice_pdf.py
# DO NOT TOUCH - Marco 2014
# (if you touch it, the delivery notes break too)You think: while I’m at it, I’ll upgrade the library. You upgrade the library. The invoices look fine. The delivery notes now print in Times New Roman, upside down.
🐄 Ten hours, times two, next unit: twenty days. Don’t make that face. I didn’t touch Marco’s file. You did.
There’s a name for this feeling too. Tom Cargill at Bell Labs put it best, and Jon Bentley made it famous in 1985: the first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent.
Tuesday · Accounting enters the chat
Accounting reads your test invoice and has one question: what happens to the old invoices? If someone reprints an invoice from March, it must come out exactly as it was sent in March. Without the phone number. Or with the phone number they had in March?
So now you need versioned templates. And the phone number has to be saved with the invoice at the moment it’s issued, not read live from the CRM.
🐄 See? Software is never finished, it just keeps changing. Two gentlemen called Lehman and Belady wrote it down in 1974: a system in use must keep being adapted, and every change makes it more complex, unless someone does the work to simplify it. Guess who that someone is.
Wednesday · The diagram on the whiteboard
You draw what you’ve found. The invoice module reads the customer table directly. The CRM sync writes into four different tables. The delivery notes share half the template code. Everything touches everything.
And the thought arrives, beautiful and terrible: to do it properly, we should rewrite it all. A proper customer service, proper document templates, a proper architecture.
🐄 Twenty days, times two, next unit: forty weeks. Want me to do it once more? Eighty months. Almost seven years. For a phone number. Moo.
estimate ×2 and next unit
5 minutes → 10 hours
10 hours → 20 days
20 days → 40 weeks
40 weeks → 80 months (≈ 6 years and 8 months)Daniel Kahneman and Amos Tversky gave this a name in 1979: the planning fallacy. We estimate by imagining how this job will go if everything goes well, and we ignore how similar jobs actually went. Everyone who has ever said “five minutes” has done it.
And for the urge to rewrite everything, there’s a famous cautionary tale. In April 2000 Joel Spolsky wrote that rewriting code from scratch is “the single worst strategic mistake that any software company can make”, citing Netscape: by the time version 6.0 reached its first public beta, almost three years had passed since version 4.0. There never was a version 5.0.
Thursday · The cow’s plan
🐄 Right. Listen to the cow. John Gall wrote it in 1975: a complex system that works is invariably found to have evolved from a simple system that worked. So we do the simple thing that works, and we let it evolve.
The plan fits on a sticky note:
- Brambilla and accounting choose one number: the billing contact.
- When an invoice is issued, the number is saved with the invoice. Old invoices stay as they were.
- A new version of the template next to the old one. Marco’s file stays untouched, out of respect.
- The library upgrade goes back to where it came from: a separate task, for another day.
- The big architectural cleanup goes into a file called DECISIONS, split into small steps, to be done one at a time alongside normal work.
Friday at 16:00 the first invoice with a phone number goes out. Total time: just under three days of work. More than five minutes, a lot less than seven years.
Friday, 17:55 · Brambilla, again
Dr Brambilla comes back, delighted. “Wonderful work. Listen, while we’re at it, can we add the email address too? It’s easy. Five minutes.”
🐄 Moo.
Moo. 🐄
Sources
The characters and the story are invented. The laws are real.
- Wikipedia, “Murphy’s law”
- Wikipedia, “Hofstadter’s law”
- Wikipedia, “Ninety–ninety rule”
- Wikipedia, “Lehman’s laws of software evolution”
- Wikipedia, “Planning fallacy”
- Wikipedia, “John Gall (author)”
- Joel Spolsky, “Things You Should Never Do, Part I” (2000)
- Rodney Bliss, “Double It And Move To The Next Unit Of Measure” (an example of the folklore)