Amdahl to Zipf: Ten Laws of the Physics of People

pieterhpieterh wrote on 08 Oct 2015 09:34


When we make software, laws of physics apply. I call this the "physics of people." When we ignore these laws, our work collapses like a badly designed bridge. Maybe you didn't realize Einstein's Equivalency Principle applied to you? Then read on, and be enlightened…

1. Newton's First Law of Motion

Everything we do has an economic motive. Things only move as a result of energy coming from somewhere else. People and organizations also follow this law. Economic motive is a force. The more accurate the economic motive, the more accurate the direction of movement. If a factory produces 500,000 rubber boots because the CEO has a boot fetish, that's inaccurate. If it's responding to rising sea levels and demand, that's accurate.

Lesson: give every team and individual access to accurate economic incentives.

2. Newton's Second Law of Motion

The bigger the team, the more force it needs. Sometimes it's a bike. Sometimes it's a car. The smaller the thing you want to move, the easier and faster it moves. If you try to change a 5,000 person company, you need massive force. To change a two person team takes a few beers and a single client.

Lesson: smaller teams move faster than larger teams, given the same force.

3. Newton's Third Law of Motion

When you push an organization, it pushes back. Or, put this another way, if you try to change a 5,000 person company, you will be fired. Unless you're the CEO. Then you'll be given a huge bonus, and then fired.

Lesson: build fresh organizations instead of changing existing ones.

4. The Equivalency Principle

Falling is indistinguishable from making progress. Until your face hits the pavement, you will believe you're in control. Since all movement is a reaction to an external force, you can only judge your success by aiming for the pavement, and failing.

Lesson: the bigger your leaps, the more damaging your failures.

5. Murphy's Law

If it can break, it will break. In fact the full law adds, "in the worst possible way, at the worst possible time." Failure isn't just all around us, it's inevitable. We cannot make perfect systems. Rather than trying to prevent failure, we need to learn to embrace failure, and make it part of our process.

Lesson: embrace failure as the best way to learn what works.

6. The Uncertainty Principle

The more you know about one topic, the stupider you become. Or, as my mom used to tell me, "never trust someone who has all the answers, especially yourself." Experts are dangerous, if they are not balanced by naive laymen. Diversity is more valuable than expertise.

Lesson: diversity is not a political slogan. It's the basis for collective intelligence.

7. Zipf's Law of Power Distributions

20% of any system always has 80% of the power. It applies to cities, languages, earthquakes, and economies. And organizations, and software systems. You'll spend most of your effort on a fraction of the software. Over-engineering code that isn't in the critical path is a waste of time.

Lesson: if shitty code solves the problem, it's not shitty code.

8. Moore's Law of Cost Gravity

Cool stuff gets 50% cheaper every 18-24 months. Whether we like it or not, our software lives on an exploding cloud of silicon. Pavel Baron said, "architecture is dead." Even a single program behaves differently than its authors believe. This is why we need profilers, to optimize code. A system with many pieces is unknowable.

Lesson: the size of our systems — the number of moving pieces — doubles every 18-24 months, and no-one fully understands any system.

9. Amdahl's Law

The more you need consensus, the less work you can do. If you spend one hour a day in meetings, that limits your effective team size to eight people. At best. In practice most of us spend a lot more time getting consensus before we can start working. Do you need approval to start on work? Do your team have standards for language and platforms? Do you have to wait for approval to put your patch into production? These are all wait states. The maximum effective size of most teams is probably less than five.

Lesson: read about the Actor model, and become a message-driven, zero shared state Actor.

10. Conway's Law

The software you make looks like your organization. If you are in a shitty organization, you will make shitty software. To grow a large scale decentralized system (and nothing else survives these days) you grow a large scale decentralized organization. If your organization causes you pain, the software it makes will cause pain to its users.

Lesson: if you're not happy in your job, build yourself a better job.


Add a New Comment
Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License