pieterh 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.
Comments
I was diagnosed of genital Herpes for 8 years, and ever since then i have been taking treatment to prevent outbreaks, burning and blisters, but there was no improvement until i came across testimonies of Dr. Timothy on how he has been curing different people from different diseases all over the world, then i contacted him. After our conversation he sent me the medicine which i took according to his instructions for up to 21 days. After completing the medication i went back to my doctor for another test and the virus was all gone and i was completely cured, since then i have not had any signs of outbreak. I'm so filled with joy. With herbal medication Herpes Virus is 100% curable. I refer Dr. Timothy to everyone out there with the virus. His email address is moc.oohay|noitadnuoflabrehhtlaehdoog#moc.oohay|noitadnuoflabrehhtlaehdoog .
How did you calculate the effective team size from the number of hours that team members spend together in meetings?
From Wikipedia's explanation:
Here is the logic, as far as I can tell:
If a project takes 20 days for one person, and there is part of the work that takes one day, and which cannot be sped up, then your effective maximum team size is 20. (1,000 people will still complete the project in min. one day).
So if your teams spends 5% of its time in meetings, its effective maximum size (assuming there are all other tasks can be done in parallel) is 20. If it spends 20% of its time in meetings, its effective max. size is 5.
Remember that your "effective team size" is always relative to a single person working smoothly. It's not because everyone seems to be working that they are in fact doing so.
So in practice this figure is fuzzy. Individuals are not perfectly efficient, and teams get pulled into many forms of inefficiency beyond meetings. Planning meetings are a symptom rather than direct cause of slow, blocking processes.
Portfolio
It took some time to wrap my head around it, but I finally understood.