As a developer, how often do you stop to understand a task before jumping to code?
Most of us have either been or worked with someone who does not question requirements, is reluctant to ask clarifying questions, or doesn’t care enough. Perhaps you’ve been that person. It’s easy to get the next ticket on the TODO column and assume it was well thought.
It’s possible you assume that the person who came up with a feature request thought about all edge cases.
From my experience, this is almost never true.
Usually most questions and edge cases only come up when you start working on a story. You may only realize you have to care about some scenarios that were not thought carefully before when you start writing your tests.
And not thinking about everything beforehand is totally fine if you work on an agile team. In fact, a complete requirement gathering and documentation done before the implementation starts is a characteristic of a waterfall approach, which is something to absolutely avoid if you care about your team being able to adapt, evolve and build software that is as simple as possible.
We also have to account that communicating effectively is hard.
We, as developers, may not understand exactly what is going on inside the head of the person who writes a feature request. So even if they indeed had thought about all possible edge cases, it is possible that something got lost in communication.
As consultants at thoughtbot, a big part of our job is to ask questions and even push back on decisions from our clients. We want them to be successful, and that means we have to be always questioning, raising concerns and communicating with other people on the team, instead of just abiding by the words of others. By doing that, we can collectively build better software products.
