Alula ሐawando

Simple question to ask when joining a software development team.

These are simple but insightful questions to ask when joining a new team. Asking questions is one of the skills we have to continously improve as engineers. We can learn and teach a lot by just asking questions with open mind.

As times goes on, I find myself asking questions regarding:

  • The code I and my team members wrote, and
  • The design decisions we have made and we are making,

Eventually though I find it lacking. I still struggle on how many issues are left uncovered after a good sprint planning.

Hence, I have planned to view every user story and/or future demands with the 5 wh questions.

  • Why?
  • What?
  • Which? Where?
  • When?
  • Who?
  • How?

Why are we building this feature or user story?

As is the case with most of these questions, there is no easy answer. In fact, you should ask to uncover more questions than to find asnwers. The why we are building this feature or user story is a good question. Mainly bacause it could shape the direction of the next questions. It could decide the fate of the feature. We could land to an answer like "We might not even need to build this future, the user could do it like this".

What are we building?

This seems straight forward, but you will the moment you join a real software development team, you might find youself puzzled by certain demands. So always ask. You would certainly find different answers from different teams. Make sure you know what is expected from the business development team, the UI/UX team, the QA team, the database team, etc.

Which feature? Where to

Which feature is this user story grabbing data from? Where is it data going to be persisted?

When do you want this feature to be completed?

Don't forget deliverables are what people want from you the most. And you should always aim to ship and to ship fast. Asking these questions, and have a realistic estimation.

Who developed similar features before?

Not just that, who are the developer in the team who decide

How do I develop it?

This is an area where we are most familier with. The how to design our class, the interactions with the methods, etc. All the internals that we proud over. But before you rush and suggest a design pattern, just ask how the team usually handles these scenarios. Don't focus on the answers. Focus on the discussion, the questions, the opinions, and why people have all these opinions.

After all, we are in a software development team to work together. If all of us caged, complaining and cranky then there is no fun in software development.