Tired of Erlang Innards

As technical people, we love to talk about technical things: pointers in C, functional versus imperative programming, or the latest in distributed P2P source control. We love to talk about them because they're difficult to talk about, they're full of cool, minute details, and yet everybody can have something useful to say.

How can something be so technical and yet everybody be able to contribute? Because the conversation is happening at an abstract enough level not to have any practical, real-world implications. It's the old story of painting the bike shed: as long as the decision makes no difference, everybody has an important contribution to make. The degree of rancor in an academic discussion is inversely proportional to the amount of real-world difference the discussion makes. And we get into some really rancorous discussions in the technology sector.

It's especially seductive to technical folks like me, because it really seems like you're talking about something important. What is best for programming, functional or imperative languages? Should a language have the fewest number of tokens, or should it be expressive enough to directly translated business language into change with as few translations as possible? These can be really important issues for a team to discuss -- or not.

Look at it this way: abstractions are like trench warfare in World War I. Over here, in our trench, is the things we do day-to-day. Over there, in the enemy's trench, is a far away land that, until we get there, has little practical meaning. In between is a vast no-man's land of abstractions and fuzzy discussions. The fog of war. Something very useful has to happen out there, but we always must be aware of where we are if we're going to win.

What gets me is when you have this facade, this patina of practicality, such as a post explaining the virtues of git, without any discrimination factors to use to tell if it's practical or not. Speaking of git, a few months ago I had a long discussion with a guy about it. It boiled down to me asking "why should I care?" and he repeating all the features. He was right -- it has a lot of great features. But I was right too -- this was a conversation without any discrimination function. It was like asking: do you like chocolate ice cream? I like chocolate ice cream. Who doesn't like chocolate ice cream?

How many large corporate systems have been specified by people reading advertising brochures and taking the features from the brochures and putting them in the spec? Without a discrimination function, everything looks the same.

It gets a little tiring.

I had a mainframe team come to me a few years ago. They had a simple proposition: tell us how to run a mainframe project in an agile fashion or admit that you can't run agile mainframe projects. Seemed like a reasonable question, until you realize there is no one way to run an agile project. The whole point in creating and running small, adaptive teams is that you don't know optimum work patterns going in. If you could, it wouldn't be an agile team. You'd just write an instruction book.

But the conversation had that feeling of technicality, of one person technically challenging another. The geek dance. Explain this. Let's debate that. Show me how, in the abstract, to do such and such. Show me you're smart. Many times these conversations are like that. I sound better talking about C++ because I can talk about the order of destructors being called in a multiple-inheritance scenario. You sound better when we talk about functional programming because you've got a greater grasp of continuations.

We confuse mastery of detail with mastery of relevance, or of practical meaning. We generalize from "this person knows a lot of detail about X" to "this person must be correct about whether A is better than B" But they're not the same.

One of the worst things that can happen for me training agile teams is to have a successful team. Sounds weird, I know. But what happens is that once you work on one really good team, you think all teams should be like the last one you worked on. The brain is always reaching to make rules and observe patterns, even where none exist. So we have to teach, even on good teams. But what we teach is give it about ten projects before you start making generalizations. Otherwise you're going to look stupid.

Lots of books have been written by authors who had success one or two times and made up huge sets of rules around how-to-have-success-in-ten-steps or some such. Even some major financial successes got started as kind of fluke cases, although to read their works later on you'd never guess it.

The problem is, nobody ever realizes that they are over-generalizing. The guy who wrote his first web app using Erlang now has all the rules for writing web apps. The guy who switched from SVN to git suddenly has all the rules for source control. The guy who voted in his first election suddenly intimately knows politics for the last 50 years.

We leave our trenches very suddenly and find ourselves in no-man's land. But like sleepwalkers, we never realize it. To us we're still having immensely practical conversations. Not only are all abstractions leaky, all generalizations false, and all standards full of exceptions, but we make abstractions, generalizations, and standards very quickly without our necessarily being aware of it.

We know a lot less than we think we do.

In the final analysis, if it helps somebody today, it's immediately practical. If it might help somebody tomorrow, it's iffy. If it could make a huge impact on world civilization in the next decade, it's total horse-hockey. The farther away from "today" and "here" you get, the more you need to acknowledge that technical details are nowhere near as valuable as general principles.

That's not to say these conversations are useless. The best we can do, in most cases, is to share stories. Perhaps offer our conclusions in a tentative manner. Tell what problems we had, how we made mistakes, and how we finally overcame them. I love abstract conversations. Just be honest about them.

Likewise everybody has to learn details, minutia. Especially in programming, these arbitrary symbols and rules are the glue that holds the modern world together. But they're not important. Not really.

Somewhere there a guy arguing the complexities of column-oriented datastores and how they beat relational databases while nothing else gets accomplished.

Don't be that guy.