Do What I Mean

IT wisdom

Table of Contents

1 Code / design

1.1 Good software [Beck]:

  1. Passes the tests
  2. Reveals intention
    • I will contend that Conceptual Integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas. [Brooks]
    • Simplicity and clarity —in short: what mathematicians call "elegance"— are not a dispensable luxury, but a crucial matter that decides between success and failure [Dijkstra]
    • Convention over configuration
    • Separation of Concerns
    • Maximum coherence, minimum dependency
  3. No duplication
    • Don’t Repeat Yourself (DRY)
    • Single Point of Truth (SPOT)
  4. Fewest elements
    • A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away. [Antoine de Saint-Exupéry]
    • Less is More
    • Occam's razor: the simplest option is usually correct
    • Keep It Small and Simple (KISS) until proven complex
    • Make everything as simple as possible, but not simpler [Einstein]
    • Measuring programming progress by lines of code is like measuring aircraft building progress by weight. [Gates]

1.2 Zen of Python

  • Beautiful is better than ugly.
  • Explicit is better than implicit.
  • Simple is better than complex.
  • Complex is better than complicated.
  • Flat is better than nested.
  • Sparse is better than dense.
  • Readability counts.
  • Special cases aren't special enough to break the rules.
  • Although practicality beats purity.
  • Errors should never pass silently.
  • Unless explicitly silenced.
  • In the face of ambiguity, refuse the temptation to guess.
  • There should be one– and preferably only one –obvious way to do it.
  • Although that way may not be obvious at first unless you're Dutch.
  • Now is better than never.
  • Although never is often better than right now.
  • If the implementation is hard to explain, it's a bad idea.
  • If the implementation is easy to explain, it may be a good idea.
  • Namespaces are one honking great idea – let's do more of those!

1.3 Snippets

  • From the Gang of Four:
    • Program to an interface, not an implementation
    • Favor object composition over class inheritance
  • In general, there are six maxims that every programmer should follow [PAIP]:
    • Be specific.
    • Use abstractions.
    • Be concise.
    • Use the provided tools.
    • Don't be obscure.
    • Be consistent.
  • General naming:
  • ​Unix philosophy
  • Graceful degradation
  • Make the change easy. Then make the easy change.
  • Technology develops from the primitive via the complex to the simple. [Antoine de Saint-Exupéry]
  • Command Query Separation: Functions that change state should not return values and functions that return values should not change state.
  • Death by Arguments
  • Refactoring Catalog
  • Principles of OOD:
    • Class design:
      • SRP (Single Responsibility Principle): A class should have one, and only one, reason to change.
      • OCP (Open Closed Principle): You should be able to extend a classes behavior, without modifying it.
      • LSP (Liskov Substitution Principle): Derived classes must be substitutable for their base classes.
      • ISP (Interface Segregation Principle): Make fine grained interfaces that are client specific.
      • DIP (Dependency Inversion Principle): Depend on abstractions, not on concretions.
    • Package1 cohesion (what to put inside packages):
      • REP (Release Reuse Equivalency Principle): The granule of reuse is the granule of release.
      • CCP (Common Closure Principle): Classes that change together are packaged together.
      • CRP (Common Reuse Principle): Classes that are used together are packaged together.
    • package couplings (metrics that evaluate the package structure of a system):
      • ADP (Acyclic Dependencies Principle): The dependency graph of packages must have no cycles.
      • SDP (Stable Dependencies Principle): Depend in the direction of stability.
      • SAP (Stable Abstractions Principle): Abstractness increases with stability.

2 Projects / management

About IT:

  • IT connects people and systems
  • IT is a craft
  • IT is human labor


  • Deploy Early and Often (DEO) / Release Early, Release Often (RERO)
  • Problem vs Work
  • Realistische ambitie
  • Pareto principle: 20/80% rule
  • Lacking quality, rules abound.

3 Aphorisms

Brooks's Law Adding manpower to a late software project makes it later
Clarke's third law Any sufficiently advanced technology is indistinguishable from magic.
Reverse any technology that is not like magic, is insufficiently advanced
Conway's Law organizations which design systems are constrained to produce designs
  which are copies of the communication structures of these organizations
Law of Demeter For all classes C, and for all methods M attached to C, all objects to which M sends a
  message must be M’s argument objects (including the self object)
Hanlon's razor Never attribute to malice that which is adequately explained by stupidity.
Hofstadter's Law It always takes longer than you expect, even when you take into account Hofstadter's Law.
Murphy's law Anything that can go wrong, will go wrong.
Finagle's corollary …at the worst possible moment.
Muphry’s law Any correction will introduce new errors.
Parkinson's law work expands so as to fill the time available for its completion
Peter principle managers rise to the level of their incompetence

4 Abbrs

DRY Don't repeat yourself
DWIM Do What I Mean
​REPL Read Evaluate Print Loop
SPOT Single Point of Truth
  Stupid Previous Owner's Trick
TL;DR Too Long, Didn't Read


binary deliverable
©2019 otech-nl