Asking the Right Questions

Obtaining requirements from stakeholders requires asking questions, not just any question, but the right question. Asking the right questions bridges the gap between what you think the client wants and what the client actually needs. It is important for a software engineer to develop the art of asking questions. This means being skilled at knowing what to ask, when to ask, who to ask and how to ask the question. Mastering this skill is resourceful, because when you ask the right questions you build the right software.

Software engineering can be defined as doing what people want exactly as they want it. Only peculiarity is: we are doing this thing by instructing computers with a very weird language. So… in order to excel at software engineering, you have to ask the proper questions so you know exactly what you need to do. It’s good to ask the same question to different people, this gives you a more rounded perspective. It’s also good to ask questions which drill down to the root of the conversation topic, or the “root of the matter” as it’s referred to around these parts.

A software developer — let’s call her “Ada” — received a phone call from a potential client — let’s call him “Yusuf” — to build a “portal” where doctors can give prescriptions to their clients. Ada asked Yusuf what his budget for the project was. Yusuf said he had sixty thousand Naira for the project. Being an experienced software developer, Ada knew that this budget was not enough for the system Yusuf was asking for; but she decided to ask some questions to clarify.

“How would you get doctors on the site?”

“I plan to partner with some hospitals to have their doctors enroll on the site.”

“How do you plan on managing the doctors? Are they all individual contractors or can they join as groups?”

“We should be able to allow hospitals sign up on the portal and manage their patients.”

At this point, Ada has noticed the scope of the original idea increase. “Should these patients be tied to a hospital, or could they be individual people on the portal?”

“They could be individual on the portal, and they could also be managed by the hospital.”

Ada has used questions to ascertain that there are at least two different systems here. One for individual contractors, and another system for hospitals and hospital management. “Mr. Yusuf, from what we’ve spoken about, there are at least two different systems you want to build here.”

The contract was not signed. But both parties were clear on the reasons why this contract could not be signed.

“Asking questions” goes beyond the planning stage in software development. It should surface in every stage in the development process most especially when you aren’t too sure about a task or process and need clarification. I say “asking questions” is an art because it’s a creative activity that involves expressing one’s thoughts and feelings in order to solve a problem. As a software developer it is possible to master this art, but you need to start with understanding why you haven’t mastered it yet and then see reasons why you should. These are some reasons I think people do not master the art of “asking questions” and why they should.

1. Fear of leaving your comfort zone: When you feel that asking questions may lead to new ideas which you are not prepared to implement, then you are scared of leaving your comfort zone. I think comfort zone is like a mirage because it keeps changing as your strength and confidence grows. This means it doesn’t exist. You never really know your strength until you look beyond the mirage and go for what you want. Be brave and believe in your words so that others can believe in your potentials.
2. Familiarity: As a developer, you get to meet people as you work in teams, sometimes new people, It may be difficult to express yourself when you need to carry out activities like requirement gathering or sprint reviews. To express yourself in the best way to each person you need to be able to connect with them, have the team spirit within you and acknowledge that everyone is working towards a common goal.
3. The fear of sounding unintelligent: Asking a ‘not so smart’ question during a meeting can be very awkward. However, if you had to wait till you had a full understanding of the problem domain before you speak up then there will be no need for a question. Questions are asked to gain understanding. And so even if you ask an unintelligent question, you have made some achievement. You won’t get to ask the unintelligent question next time. And well you will get your answer, hopefully.
4. Scoptophobia — The fear of being in the spotlight : Brilliant ideas worth sharing, so many fears, intelligent questions to be asked, yet so many fears. This will keep limiting your creativity and potentials. To grow in your career, you need to be able to communicate effectively with your team members and clients. I think developers should love the spotlight. I mean you get to build cool and amazing features to save the world. You are the real heroes and you should embrace the spotlight as much as you can. When you get that special moment to ask your questions, say what you want to say and let the words fall out. Be brave.
5. Low self-esteem: Having a low self-esteem can prevent you from communicating effectively in a team and reaching out to people for clarifications. Undervaluing yourself can reduce your quality as a developer and limit your creativity and problem solving skills. When you focus on your positives and strengths, you begin to express yourself better and believe in what you say and do.
6. High expectations: There are times you feel people in your team expect so much from you and you become pressured to exceed expectations. Trying to make them feel you are good enough may hinder you from opening up and asking questions. You don’t have to be too hard on yourself. Acknowledge that we all learn everyday and be willing to learn from tasks you implement and interactions you have with your team.

Constructing the ‘right’ question may be difficult. Here are some features of the ‘right’ question.

• It is directed at the right person
• It is asked at the right time
• It is probing
• It is open-ended
• It is not frustrating

Asking the right questions at the right time in every stage of the software development process helps you identify blockers ahead of time, saves your resources (time, energy, money, etc), clarifies your uncertainties, gives you insight, builds your confidence and most importantly helps you make architectural decisions earlier in your software engineering process.