Essentials

This page lists topics about software creation that are likely to be timeless, and explores their implications.

• Axiom: all decisions should be motivated by some kind of objective or problem to be solved.

  • Every observable property of every part of the system should be there because it helps someone: a user, or a non-user, or a developer, or...
  • Solutions are context-dependent.
  • Therefore we never write the same program twice.
  • This gets tricky because some supposed problems or constraints in the context are, for lack of a better term, made up.
    • you can tell which constraints are made up by asking "why" repeatedly and looking for absurdities. E.g. "We must have 100% unit test coverage". "why?" Because it's one of Bob's KPIs. "why?" Because Bob's job is hard to quantify otherwise. "why do we need to quantify it?" So management can measure it. "why?" So they can make sure the work we do is aligned with the company's objectives. "so I'm supposed to write a bunch of tautological tests, which in my professional estimation have net negative value, so my work will be aligned with the company's objectives?"

• Software development is mostly learning. The real work of software-making is learning. Code is just the record of knowledge gained.

  • Estimate: 5% rote building, 85% learning what other people know or once knew, 10% original research.
    • "rote building" basically means typing. By my measurement, the percentage of project cost that goes to typing is 3-4%. This agrees with others' measurements of % of the type programmers spend typing, and of LOC/hour.
    • I include understanding other people's code in the "learning stuff" slice.
    • re: 10% original research: some people say that programming is mostly "thinking". That may be true in some fields, but in the kind of work I do professionally, most problems cannot be solved in a hammock. You have to read the code, and learn about the domain and the technologies.
  • Because software development is learning, we can apply everything we know about learning in general to software!
    • e.g. mastery (see MakingBadassDevelopers)
  • FastFeedback is needed due to biological constraints on cognition/learning. You can't learn if you forget what question you asked before you get the answer! The DohertyThreshold is probably an immutable fact of human psychology.
  • HumanJudgement is needed to decide what to learn/explore next. This is true in science, too, and always has been.
  • SoftwareQuality is needed in order for us to be able to comprehend and manipulate the representations of our knowledge

• right-branching = easy to understand, center-embedding = hard to understand. This is related to the way humans process language and recursive structures generally. It's not just biology, but math: right-branching structures allow the mental equivalent of TailCallElimination, while center-embedded structures cause our mental stack to deepen. E.g. "the rapidity that the motion that the wing that the hummingbird has has has is remarkable" —Steven Pinker

• Process

  • we can't fit everything in our heads, so we have to do things step by step. GeePawHill defines a "step" as a "ready to ready" (i.e. green to green) change. We start in a good state, and we end in a good state. While the step is in progress, we're not in a good state (can't deploy, tests don't pass, whatever).
  • the process, rather than any individual act or idea, is what shapes the system in the long run.
  • plan-up-front, build-to-spec is a process.

• ConwaysLaw

• ShallowHierarchy (see also DeepHierarchy, RootOfAllTestingEvil. Related to ConwaysLaw.

• internal coherence / positive space

• Wholeness

• structure-preserving / wholeness-extending changes

• growth by differentiation