Imagine this scenario:

Two people are sitting at a conference, side by side.

One of them says, “interfaces aren’t everything”. The other person says, “I would never work in a language without interfaces”.

This actually happened. The first person is me, and the second person is someone I happened to sit next to for a session. I don’t know them and was actually mumbling to myself.

Every once in a while something comes around which reminds me of this interchange. Me, talking to myself about interfaces, the other person interrupting my conversation with myself.

So, here’s the deal: not every programming language has interfaces. Even object oriented languages don’t have interfaces.

This is part two of a herminyherm-part series on naming things. Part one might be useful for you¹.

Though naming primitives¹ is a nice way to start spotting repeated values in your code, I believe naming really starts coming into its own when you start naming simple expressions. This can serve as the foundation for the actual communication work your source code will do for the next developer.

I’ve found, in my wanderings through other people’s code, that naming simple expressions tells me a lot about what is really happening in the source code itself. Some of the earliest wins I have gotten were related to names I have applied to conditional blocks, and flow control more generally.

I read an article the other day (which I will not cite, due to unsupported claims) that stated reading source code is not like reading language. They cite this article on an MIT study which states that reading code is not like reading language.

I also read an opinion piece not so long ago that states programming languages are not languages and cannot be treated as such. Though they are not languages in the anthropological sense, they may still function as languages within the context of communicating information about a problem, and a solution.

Regarding each of these articles on their own, I only have more questions. Nevertheless, I plan to ask them here, and explore a different idea regarding what the language of software might actually be.

Something I learned about years ago, and I continually preach is names. I could (and likely will) write at length about the hows and whys. I will, however, begin with a short story.

Story Time

I worked with a couple of other developers who, in my estimation, are some of the finest damn folks I’ve had the pleasure of working with. During our time together we explored a number of ideas, and ran lots of experiments. One of these experiments was applying the “Seven Stages of Naming” as designed by Arlo Belshee, and run through our own personal filters.

We chose to work on the Tennis Kata, which, if you’re not familiar with it, is a wall of text, a couple of simple tests, and the rules: refactor the code, don’t break the tests.

The world around us contains a number of contextual clues we have become so comfortable with, it’s common to forget they are there at all. These contextual clues are often referred to as affordances. An affordance is a contextual clue about the way something works, or what it does. This is generally applied to the environment surrounding us, but it can also be applied to things like visual design.

I was listening to a podcast a while ago and a discussion came up regarding why leaves are green. I found it fascinating. I’m neither a chemist nor a physicist, so I didn’t realize that green light is the most energetic light. I did, however, know that visible color is light which is reflected away from a surface.

There is certainly more legacy code in this world than any other kind of code. I say this with only anecdotal evidence, but given the amount of time people have been writing software, the amount of time people have been creating new software, and the number of people who talk about the pains and repairs of legacy code, it seems reasonable to assume that legacy code is out there in abundance.

I’ve heard of several teams programming in mobs using the concept of the mobodoro. I believe in the notion of parallel development, so I’m not going to claim I am the sole inventor or coiner of the term, though I believe I introduced it at my current department. Instead, I want to share my personal discovery of the mobodoro and how it developed in the mobs I’ve worked with.

I started writing a long, wordy post all about ECO mapping, how it works, why you should use it, and the entire process of generating the map from the top, down. It was WAY too much.

Michael Feathers defines legacy code as code without tests. This means code written years ago, with a good test harness, is not legacy code. It also means the code written yesterday, without tests, IS legacy code.