Exercises in Simplicity

The more time I spent on software development, the more I come to appreciate simplicity. When software is buggy, slow or lacking features, that is annoying. But as long as it is simple, I can still understand the limitations and work around them or even fix them. When something goes wrong in a complex program, it is often not worth spending the huge amount of time necessary to even understand what is happening. Instead of learning about the problem your software solves, you are drowned in build tools, pre- and post-processors, too many layers of abstractions, many different APIs and huge amounts of dependencies.

Dealing with simpler software is more satisfying for me and provides a faster way to deep understanding. I want to write a few posts about the different ways I approach simple software. Sometimes, I want to replace a program I use by something simpler, in other cases I just want to try something out in order to learn how much of the complexity of common solutions is really necessary.

Guidelines

Simplicity is more important than features.

Usability must not suffer too much.

If I start with something minimal, some growth over time is ok. The important thing is a high ratio between benefit and increase of complexity.

Exercises

This web site itself[1]

Vim instead of IDE (see my vim config[2])

Use suckless software on my desktop[3]

Hacking on a minimal markdown-like parser[4]

1: blog.html

2: https://github.com/karlb/dotfiles/tree/master/.vim

3: suckless-desktop.html

4: smu.html

Inspiration

Niklaus Wirth - A Plea for Lean Software[5]

Suckless Philosophy[6]

John Ousterhout - A Philosophy of Software Design[7]

Jonathan Blow - Preventing the Collapse of Civilization[8]

5: https://inf.ethz.ch/personal/wirth/Articles/LeanSoftware.pdf

6: https://suckless.org/philosophy/

7: https://www.goodreads.com/en/book/show/39996759

8: https://youtu.be/pW-SOdj4Kkk

Quotes

Controlling complexity is the essence of computer programming.

-- Brian Kernighan

Simplicity is prerequisite for reliability.

-- Edsger W. Dijkstra

A program is like a poem: you cannot write a poem without writing it. Yet people talk about programming as if it were a production process and measure "programmer productivity" in terms of "number of lines of code produced". In so doing they book that number on the wrong side of the ledger: We should always refer to "the number of lines of code spent".

-- Edsger W. Dijkstra

Written on 2020-04-19. Last updated on 2021-01-06.