Communication
Often it seems that in software, the hard part is not computers talking to computers, but people talking to people. Communication is hard, especially communicating ideas about the design of software systems. I think there are a few reasons for this. Firstly, the software "community" (for want of a better word) is huge and dispersed and the people working in different fields will have entirely different beliefs about what is and isn't important and how things should be done. I mean, we can't even really agree amongst ourselves as to what software is (mathematics, engineering, art?) never mind how we should go about doing it.
The boring, messy truth is probably that it’s all of those and none of them at different times and how we should do it depends mostly on our particular circumstances and requirements at a given time. Unfortunately our favoured means of communicating tend to favour terse, pithy content, which doesn't play well with the nuance and subtlety of many arguments, and so can lead to lots more heat rather than light being generated. The recent #IsTDDDead debate being a good example, after the exchange of a few combative blog posts and resulting twitter wars, the noticeable thing about the (longer form) webcasts was how much consensus there was between the "opposing" parties.
I think these difficulties in communication can lead to poorly understood terminology and the gradual diffusion of ideas until their real meaning gets lost. These problems are compounded because people (myself included) are often loathe to admit when they don't understand a particular term that is being bandied about, and so don't ask for clarification or explanation.
And it’s not just new technology buzzwords that can cause problems. It occurred to me the other day when I saw a tweet showing a slide from a talk which encouraged people “not to use abstraction”. I was sort of baffled by this because to me, software is all about abstractions; and the art of writing good software seems to me to be basically the art of finding the right ones. We use it everywhere; abstractions of hardware in software for portability, abstractions of real world things or concepts in our domain models. I don’t really like the 4 pillars description of OO but there is a reason that abstraction is one of them.
So how could someone be arguing against abstraction in software? What would that even look like? From the context of the rest of the slide, it seems that abstraction here was being used to mean “code called from more than one place”, i.e. it was an argument against the DRY principle. Wrapping a bit of code in a function to avoid duplication doesn’t necessarily create an abstraction in my mind, and this is my point. Differences about meanings, even quite subtle ones, can lead to fundamental misunderstandings.
The lesson I think we can learn from this is to try and be as clear as possible as to what we mean in our communications, try as much as we can to be consistent and perhaps most importantly, shout up when we don't understand something. Feel free to flame me on Twitter if you disagree :)