The principal activity of a software engineer is managing complexity.
The Four Color Theorem provides an upper bound on the complexity of certain types of graphs, but it also provides a way of thinking about the complexity of codebases.
A series of blogs written while I worked at Rescale.
September 19, 2017
When software engineers look at a piece of code, the first question they ask themselves is "what is it doing?" The next question is "why is it doing it?" In fact, there is a deep connection between these two – why becomes what at the next level of abstraction. That is, what and why are mirrors of each other across an abstraction boundary. Understanding this can help engineers write more maintainable, readable software.
November 23, 2016
Sandi Metz recently wrote an article proclaiming that duplication is cheaper than the wrong abstraction. This article raises valuable points about the costs of speculative generalization, but it’s part of a long line of articles detailing and railing against those costs. By now it should be old hat to hear someone criticize abstraction, and yet the meme persists.
July 18, 2016
I grew up playing Magic: the Gathering. As a kid I noticed something interesting about the card names — there were no generic names. There were no cards named "Zombie" or "Elf" or "Wizard". There were cards named "Fugitive Wizard", "Llanowar Elves", "Gravebane Zombie", and even "Storm Crow" but no "Crow". Modern card names are even more specific and evocative; witness "Crow of Dark Tidings" and "Flameheart Werewolf". Why?
March 31, 2016
Every mature MVC application has that one model that’s grown out of control. The table has 20 columns; there are user preferences stored in it alongside system information; it sends email notifications and writes other models to the database. The model encompasses so much application logic that any new feature is likely to have to go through it. It’s the class that makes developers groan whenever they open it up.
How did we get here?
May 28, 2015
The world is incredibly complex, and nowhere is this more evident than the art of writing software. Software is the result of intricate interactions between social structures, business desires, and limited knowledge. The complexity of those interactions inevitably shows up in code structure. Our job as engineers is to manage this, and prepare our abstractions to handle increasing complexity over time. The most important technique in this regard is to make space for pieces of logic to take on more complexity without drowning in it – with complexity, the dose makes the poison.
January 29, 2015
The SOLID principles of object-oriented design provide good guidelines for writing code that is easy to change, but for some of the principles, the motivation and value can be difficult to understand. Open/Closed is particularly vexing: software entities (classes, modules, functions, etc.) should be open for extension, but closed for modification. What does it mean to be extended but not modified? Does this principle lead inherently to deep, convoluted class hierarchies?
December 12, 2014
There has been a lot of talk in the software engineering world about the pains associated with OOP and specifically mutable state. Side-effect free Functional Programming is often touted as a solution. While there are some salient points on mutability, the real issues arise from naive use of implicitly mutable objects. If done properly, mutable state can be a useful tool for reasoning about code, and can guide future developers naturally and seamlessly towards correct code changes.