Flexibility means adaptability to different purposes and circumstances, including ones that were never even considered by the original designer. While we value simplicity, we know that very simple systems can also be inflexible, and this principle exists as a counterweight to that kind of oversimplicity. Ideally, one should aim at a mutually supportive balance between simplicity and flexibility.

Computing systems should adapt to the changes in their operating environments (especially in relation to energy and heat). 24/7 availability of all parts of the system should not be required, and neither should a constant operating performance (e.g. networking speed).

If it is possible to imagine all the possible use cases when designing a system, the design may very well be too simple and/or too inflexible. Smallness, simplicity and flexibility are also part of the "small, sharp tools" ideal of the Unix command line. Here the key to flexibility is the ability to creatively combine small tools that do small, individual things.

What can YOU do

With or without a computer

  • Identifying inflexibilities in digital systems can be simple (e.g. it breaks immediately) or difficult (e.g. it refuses to work in some way but it's very unclear why). It is important to not give up in both cases. Is it reasonable that the system is inflexible in this way? Can we raise this as a discussion with the designers?
  • You do not have to be always available yourself. Speaking of flexibility, if we collectively refuse to always being available, our devices don't have to always be on, online, at full speed either.

When creating and maintaining software, digital tools or infrastructure

  • Consider the idea of static and runtime flexibility. Static flexibility defines what the system can do in general, whereas runtime flexibility refers to how it can adapt to a changing environment (e.g. changes in temperature, energy and network availability).
  • Computing technology in general is very flexible because of its programmability. Programming and programmability should be supported and encouraged everywhere, and artificial lock-ins that prevent (re)programming should be broken.
  • Design systems you can gradually modify and improve while running them. In this some case this could also means designing a self-obviating system.
  • In a long term, software and hardware systems should not get obsoleted by changing needs and conditions. New software can be written even for old computers, old software can be modifed to respond to new needs, and new devices can be built from old components.

Principle in Action