Words we should stop using - a glimpse into project management jargon
Conversations about software projects are packed with jargon. But if you’ve been in the industry for long enough, you may not notice it anymore. Just bring in someone from a different industry though, and they’ll be surprised by some of the words we are using.
That is because some of the words are really quite odd when you come to think about it. A few of them might even be harmful.
Words have a tremendous amount of influence on how we think and interact. This is why I started to look for better alternatives.
Here are a few of the words I have trouble with:
Deadline: Let’s be honest. In many software projects, no one is going to die if we deliver after the so-called deadline. But why do we keep using that word? Is it to install some sense of urgency in people? It certainly failed to impress me. Why not say “target date” or “time limit” instead?
Headcount: Every time I hear the word headcount, I start thinking about the medieval practice of sticking your enemies’ heads on spikes outside of your castle’s walls. Managers like using this word when they talk about allocating people to projects. We can convey the same meaning with a lot less cruelty and just say “team size”.
Estimate: Developers are often asked to estimate how long a particular piece of work is going to take. Unfortunately, people always ask for an estimate, but rarely want one. They should really ask for a “commitment” instead.
Sprint: This word is commonly used in sentences like “how much have you got done this sprint?” or “it will be done by the end of the sprint”. In most places I’ve worked at, the word “sprint” could easily be replaced with “week” or perhaps “iteration”. But I guess the word “sprint” conveys more urgency, although it is very strange to find yourself in a “sprint”, week after week with no rest in between.
Leader: I feel quite strongly about this one. I guess I’ve come across phrases like “the leadership group” or “leadership meeting” once too often. They tend to be for managers only. But managers are not the same as leaders. Managers are appointed by the business. Leaders emerge through their work. This is why you won’t find many leaders in “leadership meetings”
Backlog: How often have you heard “let’s add that to the backlog”? It sounds like a promise to get back to it later. But in reality, almost nothing that makes it into the backlog will find its way out of it again. A better term might be “won’t do list”.
Technical debt: This word has a very specific meaning and I bet it has very little to do with what you call technical debt. The term was originally meant to refer to the gap between what you know about a domain and what the code says about it. Nowadays, we use it pretty much as an equivalent for “sloppy work” or “cruft”.
Strategy: A popular thing for managers to do is to come up with a strategy for their slice of the company. The word strategy sounds important and particularly smart. Unfortunately, a lot of the things that get called “strategy” are really just “objectives” or “lists of stuff we want to get done”. The crucial bits, which are diagnosis, guiding policy and concrete actions are almost never there.
Refactoring: Developers like to ask for more time to refactor, maybe even to conduct big “refactoring projects”. But the term refactoring is nothing that you need to ask permission or time for. It is simply a part of your regular job. I like to think about it as keeping my work area clean. Would a chef ask the restaurant owner if they are allowed to clean the kitchen? If you want to make larger changes to your code base, you are probably talking about a “reengineering project”. In those cases, you should definitely ask for permission.
I’m sure there are plenty of other words that could be improved, but these are the ones I feel strongly about.