Your “Philosophy of Software Design” TL;DR

I read it, so you don’t have to.

This article contains my TL;DR (aka SparkNotes) of A Philosophy of Software Design by John Ousterhout. But, if you like this article, I would 5/5 recommend this book.

1. The idea of “complexity” in software is, well, complex

In designing software, your entire goal needs to be to remove average complexity from your program. How do you know if your software is already simple and well-designed? Well, your software is not complex if it:

• Does not require vast code changes for small alterations, like a parameter rename, a color change, a new URL of a downstream service, etc. This is related to the DRY principle.
• Minimizes the amount of information a reader of your code needs to know to understand any given section (function, module, class, etc.) of it. There should be no hidden gotchas under any circumstance. This is related to the Law of Leaky Abstractions
• Is easily altered or changed by new developers. If a new person on your team has to ask too many questions to accomplish a “starter” task in your repository, you’ve designed your software with too much complexity.