In the software literature, sometimes "transparent" means transparent, and sometimes it means opaque. This week, I explore the history behind both uses, and try to find a synthesis: explaining.software/archive/…

For the next few weeks, we'll be exploring both sides of this coin. To start, we'll look at the simplicity of keeping things apart: explaining.software/archive/…

This intuition arises from our industry's decades-long treatment of coupling as, at best, a necessary evil. And, in my opinion, it's entirely wrong. Cohesive code doesn't have to be understood all at once. Rather, it's best understood incrementally: explaining.software/archive/…

Almost every discussion of simplicity in the software industry builds atop the coupling/cohesion dichotomy introduced by Stevens et al in dl.acm.org/doi/10.1147/sj.13…. There, they defined relationships inside functions as "cohesion", and every other relationship as "coupling".

I wrote about why coupling has an unfair reputation in software design explaining.software/archive/…

I wrote about the three-part structure of explanations in software development: explaining.software/archive/…

For the past few years, I've been working on a book about software design. Lately, I've been feeling the need to ensure that its core ideas resonate with a broader audience. As such, I've started a newsletter: explaining.software/archive/…

I recently gave a talk on some ideas from my upcoming book on software design: youtu.be/tHThXQr7wwA. There’s a lot I didn’t have time to cover, but I think it conveys the general perspective I’m taking and some of the central themes.

if you can’t think of a good gift for your first anniversary, remember that the traditional theme is paper