Is crashing the database a bug?
Go beyond user stories to ensure Fitness for Purpose

One of our recent customers was building a custom software application with a single sprint team consisting of multiple in-house developers and one Lighthouse tester. At the end of an early sprint, our tester found a total of seven bugs: three of which the developers agreed with, and four of which they did not. The developers argued that these four bugs were not specified clearly enough in the user stories and shouldn’t be considered actual bugs.

The three bugs they agreed with were about conformance to specification (i.e., did the app work as specified in the requirements). Whereas the four bugs they didn’t agree with were about fitness for purpose (i.e., did the app work as it was intended). When developers focus solely on satisfying the user stories, rather than also considering the big picture (intended functionality), they develop both tunnel vision and poor-quality software. Thankfully, our tester knew this and prevented unnecessary, critical bugs from slipping through the cracks.

One example — When the Lighthouse tester entered certain values in a data entry field, it crashed the database. Let me say that again. It freakin’ crashed the database, and the developer argued that it wasn’t a bug. Although the user story did not specify that it shouldn’t crash the database, this should have been a given. (Side note – Good error handling and, ummm, not crashing the database should always be inferred requirements!) One can infer that there are certain fitness for purpose assumptions that developers can and should always make; however, in this case, our customer’s development team was clearly not making them.

Another great example of this is when the application requires a list to be displayed on the UI. Often, the user story doesn’t specify that the list needs to be sorted, but everybody knows that it needs to be. Depending on the list, it could be sorted alphabetically, chronologically, etc. but should never be generated and displayed unsorted. This is a fitness for purpose requirement that is always implied and doesn’t typically need specified in user stories unless the sorting algorithm is complicated.

When developers define success as “all requirements were met”, they make the fatal mistake of assuming that their list of requirements is complete. Nobody is perfect and we surely don’t expect that. Good developers know to ask probing questions to clarify the intent underlying complex requirements. Great development teams have productive and transparent retrospectives at the end of each sprint, where they discuss and celebrate what went well, and they have open dialog and share with each other where they can improve. In our humble opinion, this is one of the largest benefits of Agile development – the opportunity to learn and share this learning every two weeks!

It is crucial that development teams ask clarifying questions in order to build robust systems that meet general fitness for purpose expectations. Most importantly, it’s crucial that the teams develop a trusted culture where they are encouraged to fail quickly, learn, share these learnings, and improve. By making these improvements, not only will your team be more engaged, but they will prevent unnecessary rework, improve quality, and shorten time-to-market.

If your software development team falls short in meeting your fitness for purpose requirements, whether they are clearly specified or not, please share this blog with them and contact us to learn how we help teams deliver faster, improve quality, and build better culture.