"No" is a powerful and fascinating word in the English language. Simply hearing the word can create an involuntary emotion. The negative stigma and momentary sting it evokes is visually palpable. Loaded with this knowledge, why is the word so prevalent in the software industry? Often programmers catch a case of the "nos" like a bad cold. But in software development is "no" the right word? Sometimes "no" is a simple response to a complex problem. "No" is also used by developers as a defensive shield against scope creep and undefined requirements.
A great development manager once said, "It's just software." That simple statement tells a much larger story. Software development for most companies is all about time and money. Most requests can be satisfied but developers have a tendency to rebut with "no" when they believe the work is too difficult, requires extensive time, or for a variety of other concerns. This is unfortunate because the word "no" unintentionally cheats the parties involved and a software's potential.
It's important to spend the time educating others. Software development breaks down into three areas: learning, applying, and educating others. Communication is a key part of being a successful programmer. For some, stopping the usage of "no" isn't realistic, but it can be reduced or, at a minimum, clarified. Taking a few extra seconds to internally review a rebuttal can build an invaluable habit. It provides an excellent opportunity to expunge unproductive words like "no" and "can't."
Most people find that replacing "no" with the underlying explanation enables more constructive conversation. Some view this exercise as time consuming, but they fail to recognize the broader team benefit of enhanced understanding. Teams can also work to remove this word by challenging each other when it's uttered. Do not restrict these discussions to only verbal interactions. Whiteboards are an excellent communication tool for visual or kinesthetic learners. They provide an informal environment for open discussion. These discussions can result in a more refined process, new ideas/innovations, or simply a deeper understanding. All of these help build better software and relationships.
It behooves software developers to have a "how can I help you" mindset at all times. Being in software development comes with great knowledge and responsibility. Hording that knowledge is irresponsible. Take the time to educate others.