We often think that backward compatibility is hard, but actually it’s rather easy. Any project with users has a built-in mechanism for maintaining backward compatibility — people complain when it’s broken. That’s how you know. And, most of the time they let you know quickly.
The problem with this is that users can force unwanted backward . . .
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 both at . . .
(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 explaining things . . .
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 and we . . .
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 fact, we . . .
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 have many . . .
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 . . .