Five Unexpected Laws of Change
What are your core change principles? (Here are five I like.)
Hacker Laws is a collection of “Laws, Theories, Principles and Patterns that developers will find useful.”
It’s catnip to me.
A favourite quote of mine is “all models are wrong, but some are useful” (George Box); and here’s a rich collection of wrong models, many of which are useful.
Here are five that made me smile, wryly. They each punctuate a delusion I’ve held at various times during various change processes.
What would you add? Do you have any helpful rules of thumb, pithy saying, and/or time-tested principles that you use to bring your change dreams back in line with reality?
1. The 90-90 Rule
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 of the development time.
It’s like the 80-20 rule, but realistic. When you’re 90% of the way through, it’s helpful (albeit painful) to realize that you might be about halfway.
2. Brooks’ Law
Adding human resources to a late software development project makes it later.
Human resources look so neat and tidy on a spreadsheet. Look, I’ve given you one extra person. You now have that much extra capacity. Move faster!
But: Ramp-up time. Added complexity. Communication muddling. And lots of tasks aren’t divisible. (Hence: "Nine women can't make a baby in one month.")
3. Cunningham’s Law
The best way to get the right answer on the Internet is not to ask a question, it's to post the wrong answer.
It hadn’t occurred to me that the best way to shape a change plan might be to show a prototype, and get people to tell you actually how to do it. But it certainly reinforces the point that Charles Conn made in our Change Signal episode that “small experiments” trump strategy.
4. Gall’s Law
A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
Where are you heading to? And would you describe that as a complex outcome, or a simple working system that might evolve and merge into complexity?
5. Hofstadter's Law
It always takes longer than you expect, even when you take into account Hofstadter's Law.
I love that even when you know Hofstadter’s Law, you still get done over by Hofstadter’s Law.
6. Chesterton’s Fence
And as a bonus (and nudge to listen to Change Signal), Carolyn Webb and I dig into Chesterton’s Fence in our pod episode.
