Simplicity of Design

Keep it simple, stupid!

Posted by hossg on February 26, 2024 · 2 mins read

The Second Law of Thermodynamics states that the entropy of an (isolated) system always increases. In order to reduce entropy and bring order or structure to a disordered system, it requires external energy and effort.

This appears to apply to the design of computer systems and organisational structures and processes too, and is a powerful motivator for keeping designs simple from the outset. To try and do so later is very expensive.

A few tips to help with this “keep it simple” approach:

  1. Do not waste time building or organising for a future we cannot predict. Instead, design for adaptability from the outset, so that necessary changes can be made in future, but only when needed.
  2. Constrain complexity. Constraints easily can be imposed by all sorts of limits you place on the domain (‘domain limiting’): e.g. data volume, time (latency or history), synchronicity and consistency, or of course product/functional scope.
  3. Complexity is not just what is actually complex now, but what could become complex in future - even the currently counterfactual - in the event of other changes. By limiting the complexity of your problem domain you make it easier for others (or yourself in future): there is less to think about when considering a change, or solving a problem.
  4. Change process before you change technology:

    Gregor’s Law states: “Excessive complexity is nature’s punishment for organisations that are unable to make decisions”([https://architectelevator.com/architecture/it-complexity/])

    Conway’s Law states: “Any organisation that designs a system (defined broadly) will produce a design whose structure is a copy of the organisation’s communication structure“ (https://en.wikipedia.org/wiki/Conway’s_law)

    An interesting consequence of these two laws is that organisations that cannot make decisions about implementing simple communication structures are destined to have complex systems.

    It is typically easier to change process than technology, and outcomes are always better when processes and technology are in sympathy with one another, rather than in conflict.

    For this reason - and others - it is usually preferable to review and change business processes, rather than computer systems, and certainly to do so before making changes to systems. Force necessary business decisions before committing to changing technology.

    Fighting Conway’s Law is impossible, and the cost of Gregor’s Law is always far, far higher than you expect it will be.