Skip to content

Instantly share code, notes, and snippets.

Last active August 2, 2023 16:50
Show Gist options
  • Save sleepyfox/b20579302ce05a9ac9f78c6003566989 to your computer and use it in GitHub Desktop.
Save sleepyfox/b20579302ce05a9ac9f78c6003566989 to your computer and use it in GitHub Desktop.
Fox's Laws of Software Development
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

Fox's laws of software development

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.

Fox's first law of software development: small teams

"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.

Fox's second law of software development: difference between theory and practice

"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.

Fox's third law of software development: metrics

"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.

Fox's fourth law of software development: greenfield projects

"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.

Fox's 5th law of software development: employee turnover

"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."

Picture of a small fish in a big fish

Corollary to the 5th law

"The second order derivative of head count is the leading indicator of organisational failure. In either direction."

Fox's 6th law of sofware development: remote

"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.

Fox's 7th law of software development: K8s

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).

Fox's 8th law of software development: Internet publishing

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.

Corollary to the 8th law

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.

Fox's 9th law of software development: two hard problems

There are two hard problems in Computer Science:

  1. People are the hardest problem in Computer Science;
  2. Convincing people that people are the hardest problem in Computer Science.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment