On Code

The principal activity of a software engineer is managing complexity.

The Rescale Blogs

A series of blogs written while I worked at Rescale.

  • What and Why

    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.

    Continue reading →

  • Responding to Sandi Metz on Duplication

    November 23, 2016

    Sandi Metz recently wrote an article proclaiming thatduplication 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.

    Continue reading →

  • Name classNamees Like Magic: the Gathering Cards

    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?

    Continue reading →

  • The Problem with Data Modeling (as commonly practiced)

    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 className that makes developers groan whenever they open it up.

    How did we get here?

    Continue reading →

  • Plan for Unexpected Complexity or Be Overwhelmed by It

    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.

    Continue reading →

  • Open/Closed and the Single Responsibility Principle

    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 (classNamees, 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 className hierarchies?

    Continue reading →

  • Leveraging Static Typing to Manage Object State

    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.

    Continue reading →