Some simple systems need less energy, less hardware, and less maintenance. They are easier to understand, adapt, and share. By keeping things simple, we create space for care, accessibility, and long-term sustainability. At the same time, specially in relation to programming languages and hardware design, what is perceived as simple can be energy inefficient and arcane. Similarly, from scaling up datacenters to scaling up the resilience of off-the-internet wireless networks and protocols, scale is also an ambivalent notion in telecommunication, network infrastructure and topologies.

There is no magic bullet.

We acknowledge that some problems are inherently complex and achieving simplicity can be the result of a difficult and arduous process. Sometimes simplicity is simply not possible. However this phase of questioning is rarely properly addressed. The idea of uncritically "enjoying a good challenge", combined with over-engineering and scaling up for the sake of scaling up, prevents assessing if keeping it simple will suffice. Sometimes a partial, semi- or non-automated, supervised or otherwise "incomplete" solution is the most appropriate choice for everyone involved.

What can YOU do

With or without a computer

  • Let's collectively question the "unquestionable" logic of "scaling up"! Limitless growth is not the answer. Consider small-scale approaches and scaling down - can this make things more adaptable, shareable and long-lasting?
  • Don't assume you are the problem or that you don't know enough or aren't "smart enough for this". The desire for more simple systems is a legitimate and important concern which should be raised, discussed and debated. Speak out and support and encourage those who (wish to) voice these concerns.

When creating and maintaining software, digital tools or infrastructure

  • Keep it human. A system should be graspable by an individual - not just specialists. If something becomes too complex to understand, it risks failing to serve the creative spirit.
  • Low complexity is beautiful. When relevant, simplicity is not a lack but a strength. More pixels, higher resolutions, or excessive layers of abstraction don’t always equal quality.
  • Avoid pseudosimplicity. Many interfaces hide how things really work, distancing users from both knowledge and action. Being transparent also about more complex aspects invites understanding and shared agency.
  • Reduce dependencies. Relying on fewer external tools - whether hardware, software, or libraries - keeps systems flexible and independent.
  • Value wisdom over accumulation. Instead of endlessly expanding codebases, we can build knowledge and skills that outlast specific tools or technologies.
  • Think abundantly. Computing is often framed in terms of limits, but history shows that creativity thrives within constraints. What can we do with kilobytes instead of gigabytes? With slower cycles rather than infinite speed? Thinking in terms of enough rather than always more opens new possibilities.

Principle in Action