All that she wants..

It’s now a month since I first learned about the concept of Specification by Example, and I thought it was time to incorporate the practices in my hobby project; making a portable shopping list for Android. As the developer I am, I boldly set up FitNesse on my computer and thought “Now I will write some GOOD specifications with examples”. But where to start? My attempts at writing examples showed me that I was describing ‘how’ the app worked, not ‘what’ it should do. Then I realized my first mistake. My focus was on automation and code validation, not on specification at all. I needed to push back and find out ‘Why’ I was making the app in the first place. 

At least this was easy since I had ‘ordered’ the app. The desired effect I wanted was to make the grocery shopping process easier for my family. We’ve tried other app’s on the market and none of them was good enough to get my wife to use them. So I needed an app that would meet my wife’s requirements for easy grocery shopping. Eager to succeed I started writing an effect map and wrote down everything I could think of that my wife would want in a grocery app. Feeling very clever I presented my findings to my wife, and she agreed that almost everything I had written where nice features she would like. This was no surprise, since I like to think I know my wife very well. Just to be sure I had covered everything I asked her if there were other things she could think of that would make grocery shopping easier. “No, I really don’t know what is possible to do with an app, so it is a bit difficult to say” she told me. It was clear she felt that her “duty” was done and wanted to talk about other things. But just as I had learned from the course, I insisted that anything would be welcome, even non-SW items. “Well”, she said, “I get a bit hindered since I need to hold my phone when shopping, it’s much easier to hold a small piece of paper..“

Then it struck me. I had just played out an all too common scenario from our industry. Gojko warned us several times of this in his course. It’s all too easy to focus on the system we want to make, so we forget what our stakeholders actually need. When being presented with a promise of a good application she liked my ideas. But any app I make won’t turn her phone into a piece of paper, which is what she actually wants.

Hidden moral of the story: 1) Push back to find the desired business effect. 2) Always collaborate with business users when deriving the features from the goals.