The Power Of No

How many times have you used a piece of software that was full of incredibly convoluted features, strange decisions, and unusable interfaces? Have you ever wanted to physically or verbally abuse a computer because it just wouldn’t do things right, or you couldn’t figure out how to make it function properly? And how often have you thought, “How could any programmer think this was a sane idea?”

Well if you’ve ever experienced any of those things, your next thought might have been something like “**** this computer” or “**** the silly programmer who made it behave this way”. After all, aren’t programmers and hardware designers to blame for the crazy behavior of the system? Well, yes, to some extent they are. But after being intimately involved in software design for many years, I now have another reaction to poorly-implemented features. Instead of becoming angry with the programmer who implemented the system, I ask myself, “Who was the software designer who authorized this feature?” Who stood by silently and let this feature happen when they had the power to stop it?

Granted, sometimes there is no software designer at all, in which case you’re practically guaranteed to have a broken system. But when there is a software designer, they are ultimately responsible for how the system is put together. Now, quite a bit of this job involves designing the structure of features before they go into the system. But there’s also another part of the job of a software designer–preventing bad ideas from being implemented. In fact, if there’s any lesson I’ve learned from my years in the software industry, it’s this:

The most important word in a software designer’s vocabulary is “no”.

The problem is that if you give a group of humans total freedom to implement any random idea that comes into their mind, then nearly every time they will implement bad ideas. This isn’t a criticism of developers, it’s more of a fact of life. I have great faith in the intelligence and capability of individual developers. I admire developers’ struggles and achievements in software development. It’s just an unfortunate fact of existence that without some central guidance, people in a group tend to evolve complex systems that don’t help their users as well as they could.

An individual designer, however, is usually capable of creating a consistent and enjoyable experience for the users and developers both. But if that individual designer never steps up and say “no” when another developer starts to do something the wrong way, then the system will collapse on itself and become a chaotic mess of bad ideas. So it is very important to have a software designer who has the power to say “no”, and then it’s important for that designer to actually use that power whenever it is appropriate.

It is truly amazing how much you can improve your product just by saying “no” to any idea that really deserves a “no”.

Recognizing Bad Ideas

Before you can apply this principle, there is one thing that you have to know: how to recognize bad ideas. Thankfully, there are a lot of software design principles that help clue you in on what is a bad idea, and lead you to saying “no” when it’s truly needed. For example:

• If the implementation of the feature violates the laws of software design (for example, it’s too complex, it can’t be maintained, it won’t be easily changeable, etc.) then that implementation is a bad idea.
• If the feature doesn’t help the users, it’s a bad idea.
• If the proposal is obviously stupid, it’s a bad idea.
• If some change doesn’t fix a proven problem, it’s a bad idea.
• If you aren’t certain that it’s a good idea, it’s a bad idea.

Also, one tends to learn over time what is and isn’t a good idea, particularly if you use the above as guidelines and understand the laws of software design.

Having No Better Idea

Now, sometimes a designer can recognize a bad idea, but they still implement it because they can’t think of a better idea right now. This is a mistake. If you can think up only one solution to a problem but it is obviously stupid, then you still need to say no to it.

At first this may seem counter-intuitive–don’t problems need to be solved? Shouldn’t we solve this problem in any way we can?

Well, here’s the problem: if you implement a “bad idea”, your “solution” will rapidly become a worse disaster than the original problem ever was. When you implement something terrible, it “works”, but the users complain, the other programmers all sigh, the system is broken, and the popularity of your software starts to decrease. Eventually, the “solution” becomes such a problem that it requires other bad “solutions” to “fix” it. These “fixes” then become enormous problems in themselves. Continue down this path, and eventually you end up with a system that is bloated, confused, and difficult to maintain, just like many existing software systems today.

If you often find yourself in a situation where you feel forced to accept bad ideas, it’s likely that you’re actually near the end of this chain of events–that is, you’re actually building on a series of pre-existing bad ideas from the system’s past. In that case, the solution is not to keep “patching” over the bad ideas, but to instead find the most fundamental, underlying bad ideas of the system and redesign them to be good, over time.

Now ideally, when you reject a bad idea, you should provide an alternate, good idea in its place–that way you’re being constructive and moving the project forward, instead of being viewed as a roadblock on the path of development. But even if you can’t come up with a better idea right now, it’s still important to say no to bad ideas. A good idea will come eventually. Maybe it will take some study, or perhaps it will suddenly come to you while you’re standing in the shower one day. I have no idea where the idea will come from or what it will be. But don’t worry too much about it. Just trust that there is always some good way to solve every problem, and keep looking for it until you find it. Don’t give up and accept bad ideas.

Clarifications: Acceptance and Politeness

So it’s important to say “no”, but there are a few clarifications required on what I really mean, there. I’m not saying that every suggestion is wrong. In fact, developers are usually very bright people, and sometimes they really do nail it. Many developers make perfect suggestions and do excellent implementations. And even the worst solutions can have good parts, despite not being excellent as a whole. So many times, instead of actually saying “no”, what you’ll be saying is something more like, “Wow, there’s a part of this idea that is really good, but the rest of it is not so great. We should take the best parts of this idea and build them up into something awesome by doing more work on them.” You do have say no to the parts of an idea that are bad, though. Just because one part of the idea is good doesn’t mean that the whole idea is good. Take what’s intelligent about the idea, refine it, and build good ideas around it until the solution you’ve designed really is great.

Also, it is still critically important that you communicate well with the rest of your team–having the responsibility of saying “no” doesn’t give you the right to be rude or inconsiderate. If you continuously say “no” without any hint of kindness, you are going to fracture your team, cause upsets, and ultimately end up wasting hours of your time in argument with the people you’ve upset. So when you have to say “no”, it’s best to find a polite way to communicate it–a way that expresses appreciation for the input, positive suggestions of how to improve things, and lets the person down easily. I understand how frustrating it can be to have to slow down and explain things–and even more frustrating to repeat the explanation over and over to somebody who doesn’t get it the first time–but if that’s what it takes to have an effective development team while still saying “no” to bad features, then that’s what you have to do.

-Max