Why

Why Why?

Being clear on what you’re going to do and why you’re going to do it is very important.

Something that sounds like a great idea can often fall down under the scrutiny of “why?”

There’s “why are we doing this at all?” and also, “why are we doing this in this particular way?”

In the workplace, “why?” can be useful in different ways.

Sometimes, if a user is asking for a particular feature “why?” can uncover a bug that could be fixed more easily. Or, “why?” can show that the user is using the product a certain way, that the developers hadn’t thought would happen.

The reason we ask “why?” is that not asking why might lead to the wrong solution being built. If we’re building something that is unnecessary, or we have to rebuild something several times it’s generally going to be slower and less cost-effective than building the right thing from the start. Spending a bit more time at the beginning and asking the right questions before development starts can save time and money in the future. The bigger the project, potentially the more money can be saved.

Why at Work

“Why?” can also be used when speaking with colleagues.

Perhaps, using “why?” with colleagues is more precarious because it might be easy to sound somehow stupid or un-serious and lose someone’s respect.

As a developer in the workplace, one example of asking “why?” might be when a colleague has a request for a particular feature, or bugfix.

For example…

“Hi Neil, can we have a button on this page that will send people to this other page?”

A simple enough request. Someone giving such a clear and simple request might get annoyed when a developer starts asking questions.

If the colleague or client doesn’t know me very well, here is what I like to do…

• Acknowledge the request the person has made, understanding exactly what it is they’ve asked for.
• Ask why they’re asking for it. Why is it needed? What problem does it solve?
• Often, once they have explained the “why” there are follow-up questions such as… “did you know we could also do X, Y and Z as alternative solutions?”

The aim of these kinds of questions isn’t to argue, and it isn’t to say that anyone knows better than anyone else. The point is to really figure out what the problem is and to make sure we build the best solution.

What the non-technical colleague might not know when they made the request was…

• What is involved in building what they’ve asked for.
• How long it would take.
• What is possible to build.
• What is relatively quick/simple and what is relatively long in duration and complicated.

And in the same vein, I, the developer, might not know…

• How the colleagues/customers use the product.
• Which difficulties there may be in using the product.
• The level of knowledge the colleague may have about what is possible.
• Whether there are any bugs that make people use the product in a particular way.

So, I’d say that there are things that either a non-technical or technical person does not know, neither one can probably come up with the best possible solution without the other’s knowledge. And the best way to get to that knowledge is through some pretty basic questions.

When I ask the question “did you know we could also do X, Y and Z as alternative solutions?” I’m not expecting the person to necessarily say that my ideas are any better than theirs. The point is to just make sure everyone has all the relevant information. If we all know about X, Y and Z, maybe the original idea is still the best, but at least we’ve explored the options.

If I only knew that hammers existed, I might use the hammer on every screw I saw, but as soon as someone showed me a screwdriver that would change everything.

What is best and why?

It might seem strange, but as a developer I’m often more concerned about how people use the product than a non-technical person. Because I know how the product works, I want to make sure it works well and is based on user experience rather than it being a certain way because that’s the default.

So, I’m not necessarily looking for the solution that works best with the rest of the code. The best solution is best overall.

Factors in finding a solution…

• Does it do what we want?
• Does it work well with everything else?
• What is the duration?
• Are there any forseeable problems in building it?

It could be that given all the information, the client ends up just wanting a quick solution, whichever way is quickest. Or, maybe they want the best possible solution and don’t mind if it’ll take a while to build.

Even if someone were to ask for the quickest solution it makes sense to at least look at what the options are. Once all the options are laid out, they might be surprised with what is possible.

As a developer, I just want to be sure from the outset that the thing I’m spending my time on has been thought through at least a little bit. If objectives change, or something else comes along, that’s ok. As long as we’re being sensible and working as a team, using methods such as asking “why?” and being prepared to be ego-less, there’s a chance we’ll get to a good solution.

Conclusion

Asking “why?” can be a very useful tool. It’s similar to “bring me the problem, not the solution”. Let’s understand the problem first, then understand the options, before one of us picks a solution.

If someone has come up with a solution independently and doesn’t appreciate any questions, they might just need an explanation of why you are asking the questions you are. By explaining the method, you’re probably less likely to cause offence.

The alternative, could be to create one solution then after seeing it in action changing our minds and deciding to build a different solution. So, while asking questions can sometimes seem like a lot of effort or unnecessary, questions at the beginning to get clarity are quicker and cheaper than building the wrong thing.