Negative Architecture
Guiding software by flipping figure and ground
You’ve probably seen this picture before. It’s one of several images that people use to show how perception works. You either see a vase or two faces looking at each other. In the terminology of Gestalt Psychology, one becomes the figure and the other becomes the ground. We can switch between the vase and the faces but we can’t see . . .
10 Papers Every Developer Should Read
(At Least Twice)
(This is a requested repost of a lost blog I wrote in 2009. I'd change a few things, but not many)
I spent most of yesterday afternoon working on a paper I’m co-writing. It was one of those days when the writing came easy. I was moving from topic to topic, but then I realized that I was reaching too far backward – I was . . .
Knowing What Is There
If you want to know about the mechanics of refactoring there are quite a few resources out there. You can even find resources that outline refactoring strategy. But what about mindset? Is there a refactoring mindset that people should be aware of? I think that there is.
A while ago I was working with a team. We had time to refactor . . .
Converting Queries to Commands
A `Slice and Dice' Refactoring
When methods focus on a single responsibility, they fall into two broad categories. They are either queries that compute and return some value without producing side effects, or they are commands that change the state of the world or the state of the object they are on.
The former style is more common in functional programming. In . . .
Edges in Software
Using Edge Cases as Focal Points for Design Choices
One of my favorite sayings is “If you take care of the corners, the room takes care of itself.”
For the longest while I thought it was something that Frank Lloyd Wright had said but I haven’t been able to find an attribution. Regardless, I think that the idea is sound. The edge cases in our software define it. Ideally, we shouldn’t . . .
Revealing Interfaces
Making Usage Patterns Explicit in Code
In nearly every OO application there’s at least one large class. By large, I mean a class that has 15 or more methods. We expect classes to have focus and it’s hard to make the case that a class with that many methods is about one thing. There will be some sort of grouping. Sometimes it’s explicit in the names of the methods, sometimes it’s . . .
Unary Call Sites and Architecture
Using Static Call Counts to Explore Internal Structure
In an ideal world we’d be able to see more in our editors and IDEs. We see our code, and that’s just about enough to work but there’s so much more that we can know.
One of the things I’d like to know is the number of call sites that each method has. In frameworks or libraries, we’ll have methods that are never called . . .