Usage changes. Language is usage. Language changes, not necessarily for the better, in my opinion.
Usage changes. You can now say things like “That’s a big ask” and at least some people won’t look at you askance. “Begs the question” no longer refers to a logical fallacy, at least at the tongues and in the ears of some people. Encountering these changes, some of us go “well, that’s OK”, while others are like “I can’t even”, and are all “why can’t you speak correctly?”
Now my mother, PBOH, was a strict grammarian, and when I wasn’t being raised by the Jesuits, it was at the hands of various Sisters Sans Merci, so I have both an interest in language and a pretty good sense of what “correct” meant, at least back in my formative years. As a result, many of these newer formulations grate painfully on my ears.
However, correct language, I have come to understand, is the language that people use to speak with each other, so if someone in your gang says “I ain’t got no money”, the rest of you don’t scream “double negative!” and “no such word!”, you understand that the poor guy is busted, and probably you stand him a few drinks or a sandwich until he’s on his feet again. That’s how your gang talks, and that’s OK.
There are issues when people from different gangs communicate. The gang with power may well associate the way the other gang speak with inferior people, “other” people. When we interview for a job, the way we speak makes a difference in the decision. Should it be that way? Arguably not, but as we say in my gang, them’s the breaks.
What about “technical language”?
Technical Usage Varies Too
One of the richest sources of language change is technology. Early on, I remember the day, we discovered what we now call “fire”. It was originally called “owowow”, but that word changed to mean hitting your thumb with a hammer (née rock) and we started calling it “fire”. We had a new technical discovery and we named it.
Later on, we invented software, and new words started entering the language. And, as is always the case, usage changed over time. One such term is “technical debt”, a relatively recent addition to the lexicon.
Technical debt originally referred to a discovery. In an existing program, sometimes we look at some perfectly reasonable code and see a better way to do what it does, a way we didn’t see before. As I understand it, Ward Cunningham originated the term “technical debt” to refer to the difference between the design we see today, and the design we have in the code. When we “repay” the debt, improving the design, that’s a good thing, and usually the program becomes simpler and more clear than it was.
Today, many people have heard the term, without access to Ward, poor devils, and they build up a meaning for it without any particular coordination with others using it.
Some people think that it is possible to “go into technical debt” by intentionally taking shortcuts, and then (presumably) paying it back later. They imagine that you can go faster by writing inferior code. I believe they are generally mistaken.
Some people think that “technical debt” just means “poor quality code”. Recently James Shore took that position. It was a good thread, and I recommend it.
GeePaw Hill chimed in. His point is that the term doesn’t work because people don’t understand debt. I might possibly agree with that, but for sure I agree with GeePaw, and (I think) with James that the term should be retired.
James also discusses refactoring in his thread. Here, contrary to giving up the losing position on “technical debt”, James wants to reinforce the notion that refactoring is small changes, and his comments are excellent. Read the thread again, that’s my advice.
Now, we could quibble with the notion that refactoring is limited to small changes, to “tidying”1. Formally speaking, refactoring is kind of recursive. Since two refactorings R1 and R2 each leave the code behaving the same but with different, presumably improved design, then R1•R2 is also a refactoring, all the way up to replacing all the code. (If you can do it in small steps. If not, we would really prefer that you call what you’re doing “rewriting” or “technical suicide”.)
There are surely other Agile-related terms whose understood meaning is changing over time. Like “Agile” itself. Most of my colleagues have given up that word, and I am tempted to do so myself, except that I have a category on my web site, and the word, capitalized, occurs about 2700 times on the site. I may be stuck with “Agile”, but I can certainly use it less.
Some of my dear colleagues have argued for the term “check” instead of “test” when referring to “automated tests”. The word “estimates” has never stabilized, ranging from “how long down to the minute will it take to do this 100 person-year project?” to “is this story a 1, or is it too big?”.
I’m sure there are more. Maybe I’ll write about them, especially if folks suggest them. But before I go, I want to talk about definitions.
Often folx, especially technically-inclined folx like me, want to refer to “the definition” of a term. They want to nail down the term so that they, and everyone else, will use it just so, with no possibility of misunderstanding. “Define your terms!” they shout.
When you shout into the Void, we are told, the Void isn’t listening.
The more you look at definitions, the less well they work. Especially if you understand recursion2, because if you do, you’ll start looking for the definitions of the word in the definition and when you start looking for definitions of “is”, well, history tells us that you’re going to be in trouble.
We do want to reach a common understanding with other folx, and despite many failures, we often choose to believe that it’s possible to get pretty close. But only so close.
One time long time ago I drew a picture indicating that there isn’t, and cannot be, a bright line between IS and IS NOT Scrum. The same picture applies to terms like refactoring, technical debt, Agile, and in fact to just about every interesting notion we’ve ever had.
Sometimes the common usage of a term deviates so far from our own notion of it that we might do best to abandon the term. I think that time has come for “technical debt”, and probably for “Agile”. With James, I’ll hold on to “refactoring” for a while, and I strongly recommend “tidying”.
When I say “final” here, I don’t mean I plan to stop thinking forever. I just mean … oh you know what I mean.
As much as I enjoy writing about code and programming, what matters in the world is what we do, together, as people. In software development, the people and the way they work together is more important than any particular practices or tools. Practices and tools do make a difference, but people working well together can transcend any flaws in their tools and can improve the tools and their practices. And people working poorly together can screw things up no matter what practices and tools are imposed upon them.
When I coach, and when I write, I’m just hoping to be understood, and I say things differently as often as I say them the same, because I’m trying to express ideas in as many different ways as it takes me to express what I think is inside me, and as many ways as it takes me to find something that appeals to a reader and gets them thinking in a new direction.
I think that what we do makes a difference, and I think that we choose what to do based on experience, and I think that we choose experiences based on things we see or hear that attract us. Words can help with that.
But what you get from this article, from all my work, from the world, depends on what you do. What you think influences what you do. What you hear influences what you think. So … try to hear a lot … and think about it.
Then let me know what you think, and what you wonder about.