I’m a big believer in the idea that words mean things. As professionals we must choose our words carefully – they affect our behavior and the behavior of those around us. Recently, there are some words I have been intentionally removing from my vocabulary because I find them to be unhelpful. For example, I have committed to no longer referring to human beings as “resources.” Whether renewable or not, resources are things that we consume like oil, water and paper. People are not resources to be consumed, and referring to folks in this way is dehumanizing – it promotes bad decision-making and causes us to ignore the intelligence and emotional needs of others. So let’s stop saying it.
“Requirement” is a word that has outlived its usefulness in software development; it is time to stop using it.
Requirement is a meaningless word.
I’ve never held a requirement in my hand or happened upon one walking down the street. It is not a real thing. We do a strange thing with the English language, particularly in business parlance by turning meaningful verbs and adjectives into empty nouns. Requirement is derived from “require” and “require” makes a strong statement. “My boss required me to attend that awful meeting yesterday” or “You must make the required payment by the due date.” Weak words like requirement are worse than verbal crutches, they are clever ways for us to avoid having meaningful conversations.
Let’s play out a scenario that happens thousands of times a day in this industry. You walk into work, grab some coffee, pass a colleague on the way to your desk and casually ask him, “what are you working on?” He replies, “I’m implementing requirement SYS-5794 today.”
“That’s great,” you say, “have a nice day!” with absolutely no idea what your friend is talking about. Now let’s suppose your coworker had said, “I’m implementing the purple cow feature today,” then you might have engaged. “Oh really?” you say, “tell me more about that, what does the purple cow feature do?” You might have helped him decide that purple cows are silly and then talked to your manager about removing them from the product entirely.
Admittedly this conversation is contrived, your friend could just as easily have said “feature SYS-5794,” but at least “feature” is descriptive of something that a person would use and find helpful. We are more likely to engage in a conversation about features and user stories than we are about requirements.
Requirements discourage MVP (Minimum Viable Product).
MVP is a modern approach to building software products where you deliver only the features and functions that allow a useful product to be deployed – nothing more, nothing less. You may add more features later based on revenue potential, user feedback, or some other driver, but each release continues to focus on building only what is needed to accomplish a goal.
Requirements by definition are required. A must do. Put your head down and code it up. There is no room to debate the need for something that is required. This way of thinking flies in the face of modern approaches like MVP. In the MVP world everyone is free to ask questions and challenge assumptions. The product owner decides when the product has hit critical mass and is ready for release. We need not wait for everything to complete if releasing sooner is the right thing to do. Requirements have no place in this environment.
Requirements give us an excuse to stop thinking.
This is a more general form of the problems described above – the word requirement gives us a free pass for not thinking. A nameless, faceless party decided which things are required for success, who am I to think differently?
Decision makers are wrong all the time. Companies with high-performing cultures empower their people to create, think critically and challenge assumptions. Google has done a pretty respectable job of building a culture of innovation; it is part of Google’s DNA as described by Laszlo Bock in his best-selling book Work Rules!.
I’ve never worked at Google but somehow I doubt they say the word “requirement” very much. If you’re a Googler and a person, not a resource, please leave a comment below and let us know!
Originally published at www.linkedin.com on November 26, 2015.