penitent, turbulent, multiplex!

In the last short, I used several analogies. I likened the craft of a software developer to that of a contract artist, or a shoemaker.

Analogies are useful things. When I have the pleasure of sitting down with a group of people who are really excited about what they do, and who are discussing a very challenging problem, what happens almost immediately is that someone will draw an analogy to help the discussion move forward.

This definitely gets the conversation moving. It’s the direction that is the rub. It’s really easy to let an analogy run wild, to the point that it gives you almost no insight on the problem you were initially trying to understand.

As an example: Just the other day, I was at a great lunch meeting where the discussion was centered around software testing. Someone mentioned that developers often write software with the assumption that the user is usually going to do things in a very predictable fashion, and that ‘weird’ cases are exactly that — weird. In this sense, the developer is living with the same set of assumptions as a traditional performance artist, where interactions are scripted, and mess-ups are assumed to be few and far-between.

It was mentioned that perhaps a better mindset would be that of the improv performer, where the fundamental assumption is that everything is going to be unexpected. The analogy was a good one — it clarified that there were two sets of axioms we could be working against, and perhaps that one of them was more appropriate than the other.

Within twenty minutes, we were talking about this one time that someone had been to a play where the lights had gone out, and the crew decided finish the performance by candlelight. The analogy had run amok. We were certainly still having a stimulating conversation, and possibly there was a lot of value in what was being said. But we’d completely lost the original point.

Usually when I’m involved in a conversation that is centered around an analogy, I try to bind the concepts within it to concepts in the topic that we’re actually trying to understand. When I hear a lot of those threads breaking, that’s how I know the analogy is taking on a life of its own.

Why do I think this is so important to being a good developer? I have two reasons. The first: When I encounter software that I think is particularly pleasant to work with, it is because the high-level metaphors that are being used to describe things are obvious and are used consistently throughout the product. If you look at a lot of patterns in software design, they’re essentially dressed-up analogies. (A “bridge” is sort of like a physical bridge because etc… an adapter is sort of like a power adapter because etc…)

The second is that I’ve observed that many smart people that I like to learn from tend to use analogies heavily. I don’t often get a lot of time with those people. And so, to really make sure that I’m getting the most out of my time with them, I like to carefully monitor the evolution of their analogies. After all, I can spend my afternoon talking about botched performances with pretty much anyone, really

(Steve McConnell does a good job of dissecting several analogies used to describe software development as a whole in his massive Code Complete, 2nd edition. I can’t say that I particularly like the one he finally arrives at (“it’s like construction”), but at least he is thorough in itemizing the components of the analogy that work, and the ones that don’t quite mesh well. It’s that sort of exploration that really helps you understand the original problem, in my opinion.)

If you’re getting paid to write software, then it’s pretty likely that the majority of the people around you understand you to be an engineer. That is, it’s your job to understand and create a practical solution to a stated problem.

I struggled with this for a while. This makes it really easy to cut corners. It makes it really easy to think of your job not as a craft, but as a requirement that just needs to be fulfilled as cheaply as possible. At least, that’s what it does for me.

I’ve managed to reconcile this within myself by the analogy of the contract artist. While in Italy, I read and heard countless stories about great works of art that were commissioned by the state. These works had very real and often very challenging engineering requirements that had to be met. And yet, there were myriad details that went into the creation of those works that had nothing to do with explicitly fulfilling the requirement, but that essentially gave each work its own life.

That’s how I think about what I do. And if you look around, there are a ton of other professions that are essentially the same. A cobbler just has to fix your shoes, but it’s the material he uses, the lessons he has learned, the attention to detail that he takes, that affects how well the job is done — even if it’s in the details that only another cobbler would notice.

When I worked in a restaurant as a teen, I learned that being called a ‘shoemaker’ was an insult. It meant you’d paid no attention to what you were doing. Now, years later, I see ‘shoemaker’ as kindred spirit.

Recently, I’ve been re-evaluating a lot of the lessons I’ve learned about what I do. The sheer number of the sorts of things I’d picked up along the way thus far sort of astonished me.

Anyways, I’ve decided to start fleshing out these ideas by writing them out in short-form. I’m calling them “software-shorts”, and the first one is going to be posted in about 2 minutes.