author: @sleepyfox
title: Fox's laws of software development
date: 27 October 2021
preamble: A not entirely serious treatise on the immutable fundamental laws of software development activities
A not entirely serious treatise
Over the years I've observed that software development is less a Science, and more an art. There are however certain laws of nature that it does well to understand and not try and defy, lest Bad Things(tm) happen.
"Any program that can be made can be made in a reasonable period of time by a team of ten or fewer programmers. If that is not the case then either: a) it cannot be built e.g. it depends on some other thing that doesn't exist yet, or b) you have the wrong ten programmers."
This was inspired by the experience I documented here: Net-negative producers.
Over the years I've seen it play out again and again. A small team of capable professionals, left to get on with it in the way that they know best, do what tens or hundreds cannot. This is the common thread throughout all of the attendees' experiences at Snowbird in 2001 that led to the formation of the Manifesto for Agile Software Development.
"There is only one difference between theory and practice, that is that in theory there is no difference between theory and practice, but in practice there is."
We've all seen them. They walk in and pronounce with great confidence that because the theory of MVP's states that because you shouldn't build a thing unless there is a proven need for it - YAGNI - that you shouldn't have built logging into your solution pre-launch. This is an actual example I had from an Architect on a project.
Until what? Until it had broken down and our customers were clamouring to know why? I've built many systems, and there's never been one that didn't need logging. You Are Going To Need It. Because practice trumps theory.
"Giving a manager a metric is like monkeys juggling chainsaws. Whilst initially it might seem impressive, it always ends badly."
I could write a book about this one. Thankfully several other people already have, so you are spared my terrible writing; from Deming's Out of the Crisis to Muller's The Tyranny of Metrics to Kohn's The case against Standardized Testing to Taleb's Fooled by Randomness.
The reality is that hardly anyone has the background to understand numbers, but we try and manage using them based upon highly simplistic and inaccurate models of systems. This very often leads to poor results. A better option is to use "management by walking around", go to the gemba, see what is going on, ask the people doing the work what is happening, and give them the authority and budget to fix things.
Another word for this is Leadership. Deming, Drucker, Ohno, Hock, Goldratt - many have talked about this.
"There are no greenfield projects."
Every project is a brownfield project. Even when you have no legacy code, you have legacy experiences, legacy world views, a legacy boss, legacy expectations and legacy trauma. Even the stuff you learn from on the interwebs is somebody else's legacy.
'Legacy trauma' probably deserves an explanation: All developers with time served have experiences in their past that they cannot bear to repeat. These form patterns of aversion that when triggered cause powerful effects. Unfortunately, the human brain is a first-fit rather than a best-fit pattern-matching engine, and false positives abound.
"When it is easier for your employees to find a new job than it is to get a promotion at their current job, your company is on the inevitable path to no longer being a small fish in a big pond, or even a big fish in a small pond, but rather a small fish in a big fish."
"The second order derivative of head count is the leading indicator of organisational failure. In either direction."
"If anyone is remote, everyone is remote."
This is simple empathy and respect for people. If you're having a meeting and one person is remote but the others are all on-site, then everybody should individually be on video-conferencing to make it a level playing field.
Really a variant of Godwin's Law:
"Given long enough, all tech discussions turn into discussions about K8s."
If you're an IaaS provider then perhaps K8s is relevant for you. For the rest of us, there are simpler options. It behoves us as professionals to always use "the simplest thing that might possibly work" (Kent Beck).
If you need to get something that was originally published on the Internet, the chance of it being retrievable is proportional to 1/(2^t), despite what some people would have you believe. That is: stuff on the Internet has a half-life.
If you need something not to be available on the Internet, it will persist indefinitely, despite all attempts to remove it. E.g. that Geocities site you made in 1995.
There are two hard problems in Computer Science:
- People are the hardest problem in Computer Science;
- Convincing people that people are the hardest problem in Computer Science.