Matthias Lüdtke's better-idea.org

Book: A Philosophy of Software Design

Mon, 08 Dec 2025 11:40:13 +0100

Several years after Clean Code, which I always found overrated, A Philosophy of Software Design (2021) felt like a real breath of fresh air.

Because the book addresses the broader question “What makes code hard or easy to understand?” it is, in practice, more useful as a guide for writing maintainable software than Clean Code, which focuses heavily on narrow stylistic rules.

Early on, Ousterhout states:

One of the most important goals of good design is for a system to be obvious.

He then analyses examples that demonstrate this principle in practice.

The key idea that stayed with me—and one I plan to explore further—is the concept of deep modules:

Deep modules: The best modules are those that provide powerful functionality yet have simple interfaces.
The most important issue in designing classes and other modules is to make them deep, so that they have simple interfaces for the common use cases, yet still provide significant functionality. This maximizes the amount of complexity that is concealed.

Ousterhout’s talk at Google is also worth watching: A Philosophy of Software Design (1 hour, highly recommended) www.youtube.com.

A few more quotes that capture the essence of the book:

Complexity is anything related to the structure of a software system that makes it hard to understand and modify the system.

Complexity is caused by two things: dependencies and obscurity.

Design systems so that developers only need to face a small fraction of the overall complexity at any given time.

jsonnormalize

Sun, 14 Sep 2025 15:04:00 +0100

I have written jsonnormalize a while ago, but I am surprised at how often I need this helper to compare some json: https://github.com/mat/dotfiles/blob/master/bin/jsonnormalize

PyData Berlin 2025 Notes

Thu, 04 Sep 2025 14:23:42 +0100

I just came back from the PyData conference in Berlin and apart from meeting a lot of great people, I took some tidbits away:

Docker’s Cache mounts can be used to solve the problem of a single pip dependency change invalidating the entire Docker cache. So instead of doing:
```
RUN pip install -r requirements.txt
```
You can do:
```
RUN --mount=type=cache,target=/root/.cache/pip \
    pip install -r requirements.txt
```
Or, equivalently, for uv
```
 RUN --mount=type=cache,target=/root/.cache/uv \
     uv sync
```
This will cache the pip downloads and speed up subsequent builds.
You can, through the magic of WebAssembly, run DuckDB in the browser: https://shell.duckdb.org
For documentation, people (e.g. like Github, Cloudflare, basically everyone) are more or less following the Diátaxis framework. I have a Dejavu feeling that I have seen this somewhere before under a different name. The idea is to split documentation into four categories: tutorials, how-to guides, explanations, and references. Tutorials and how-to guides are task-oriented, while explanations and references are information-oriented (on a need-to-know basis).
How did I miss WebLLM before?
For PDF/HTML parsing and text extraction docling is the new hotness and already very promising.

patience

Fri, 18 Jul 2025 15:30:00 +0100

Sometimes, with flaky tests, you just have to have some patience. I have written this helper script recently to use git bisect with a somewhat flaky test:

https://github.com/mat/dotfiles/blob/master/bin/patience

Unicode Symbol as Text or Emoji

Thu, 23 Apr 2015 11:23:00 +0100

Unicode symbol as text or emoji

Append codepoints.net/U+FE0E to make a Unicode symbol render as text.

When tech is fully adopted, it disappears

Sun, 02 Nov 2014 21:57:00 +0100

When tech is fully adopted, it disappears.

– Mobile Is Eating the World

Alfred: UIColor from Hex

Wed, 16 Oct 2013 16:03:00 +0100

Being tired of manually creating UIColor instances from hexadecimal representations (and not always having a category on UIColor handy for this) I finally hacked together this humble Alfred script to do just that:

E voilà, we now have this string waiting in the clipboard:

[UIColor colorWithRed:19.0f/256.0f green:55.0f/256.0f blue:66.0f/256.0f alpha:1.0f]

Download Workflow from GitHub: UIColor-from-Hex.alfredworkflow

Incremental Development — No Silver Bullet

Sun, 20 May 2012 12:58:00 +0100

Incremental development — grow, don’t build, software.

I still remember the jolt I felt in 1958 when I first heard a friend talk about building a program, as opposed to writing one. In a flash he broadened my whole view of the software process. The metaphor shift was powerful, and accurate. Today we understand how like other building processes the construction of software is, and we freely use other elements of the metaphor, such as specifications, assembly of components, and scaffolding.

The building metaphor has outlived its usefulness. It is time to change again. If, as I believe, the conceptual structures we construct today are too complicated to be specified accurately in advance, and too complex to be built faultlessly, then we must take a radically different approach.

[…] Some years ago Harlan Mills proposed that any software system should be grown by incremental development. That is, the system should first be made to run, even if it does nothing useful except call the proper set of dummy subprograms. Then, bit by bit, it should be fleshed out, with the subprograms in turn being developed–into actions or calls to empty stubs in the level below.

I have seen most dramatic results since I began urging this technique on the project builders in my Software Engineering Laboratory class. Nothing in the past decade has so radically changed my own practice, or its effectiveness. The approach necessitates top-down design, for it is a top-down growing of the software. It allows easy backtracking. It lends itself to early prototypes. Each added function and new provision for more complex data or circumstances grows organically out of what is already there.

— Fred Brooks, No Silver Bullet, 1986

Marco Arment on 'interesting' features

Wed, 26 Jan 2011 09:27:00 +0100

Geeks like us are always tempted to implement very complex, never-ending features because they’re academically or algorithmically interesting, or because they can add massive value if done well, such as speech or handwriting recognition, recommendation engines, or natural-language processing.

These features — often very easy for people but very hard for computers — often produce mediocre-at-best results, are never truly finished, and usually require massive time investments to achieve incremental progress with diminishing returns.

– http://www.randsinrepose.com/archives/2011/01/25/interview_marco_arment.html

Fowler on Craftmanship

Fri, 21 Jan 2011 01:11:00 +0100

The software shouldn’t be at the center of a programmer’s world, instead a programmer should focus on the benefit that the software is supposed to deliver.

– http://martinfowler.com/bliki/CraftmanshipAndTheCrevasse.html

Fowler on Productivity

Sun, 21 Nov 2010 10:38:00 +0100

I assert that any true measure of software development productivity must be based on delivered business value.

– http://martinfowler.com/bliki/CannotMeasureProductivity.html

Fowler and Rebecca Parsons on DSLs

Sun, 21 Nov 2010 05:02:00 +0100

http://www.drdobbs.com/architecture-and-design/228200852

Good overview, Q&A style. Remember to keep your DSL simple (otherwise it might morph into just another L)

Advanced Regular Expressions

Tue, 16 Nov 2010 11:37:00 +0100

http://www.smashingmagazine.com/2009/05/06/introduction-to-advanced-regular-expressions/

I always forget about word boundaries and back references.

Source: stackoverflow.com