When all you have is a hammer, everything in the world starts to look like a nail.
Twenty five years of doing analysis and helping others do analysis has shown me that there are at least three different types of things to specify about a system:
- What the system looks like.
- The calculations in a system, and the data needed.
- The behaviour of the system based on its internal state, and the system interactions within and without the system.
The traditional tools
Before the internet, user experience was considered of little value because most users of systems were internal employees of companies. These employees had no choice whether to use the systems if they wanted to perform their roles. Any consideration of usability tended to focus on ergonomics and prevention of damaging mistakes due to confusing interfaces.
This meant that low fidelity prototypes dominated the way people described what systems look like. Some people used visio or powerpoint to create these prototypes. My preference was Excel due to the speed of creating the prototype, and familiarity of my colleagues with Excel:
Describing data and calculations was done using a business domain model. An abstract description of the data and the calculations was specified using a tool like Rational Rose.
The interaction of the system with outside actors (humans and other systems) was described using use cases. There was no standard format but everyone was influenced by Alistair Cockburn’s “Writing Effective Use Cases”:
The traditional world of analysis was where these abstract descriptions of the system’s data, calculation and behaviour were used to drive the development of a system.
Real Customers and Specification by Example
The internet exposed real customers to organisation’s systems. Real customers had choice about which service they used. As a result, user experience (research and design) have become a vital part of product development and system design. Low fidelity prototypes have been replaced with high fidelity prototypes that are tested with real customers before software development starts. High fidelity prototypes are now part of the specification of a system, sometimes with pixel level precision.
Internet time meant fast, with short lead times. Short lead times demand automated testing, and lead to test driven development. Automated testing meant “specification by example” was needed to feed into test driven development.
Instead of abstract domain models in Rational Rose, data and calculation are specified using examples in spreadsheets with associated formal definition of calculations. In 2003, Sanela Hozic and I used a spreadsheet using examples to show the calculation of credit risk on oil transactions. This was implemented by Andy Pols and Joe Walnes in a prototype. In 2007, we used a spreadsheet containing examples to specify the calculation of cash flows for complex credit derivatives. These examples were co-created with the tester and verified and added to by the trading assistant who normally calculated the cash flows. These examples were implemented using JUnit. In 2010, Nat Pryce and team created a spredsheet based eco-system where traders entered the examples. Once again Given-When-Then was not used.
Abstract use cases and state transition diagrams have been replaced by examples in the Given-When-Then format. One of the drawbacks of Use Cases was that the approach discouraged business analysts from exploring alternative paths, which lead to a “Happy Path” mentality. The focus of the Given-When-Then format allowed the business analyst to create a “Happy Path” scenario and then hold a “Three Amigoes” session to explore “Quality Paths” (Given the volatility market data is missing) and “Technical Paths” (Given the server is unavailable). These alternatives are typically written as acceptance criteria in user stories.
The tragedy of Given-When-Then: Act I
If Shakespeare had written a play about Given-When-Then, he would possibly have started it with the line “The world appears to be made of nails when all you have is a hammer.”
Although Given-When-Then is a fantastic way to describe interactions, state and behaviour, it is a lousy way to describe data and calculations. A common anti-pattern is that Given-When-Then is used to describe data and calculations:
- Given <a set of market data and trades in a table>
- When <arbitrary event such as calculation is performed>
- Then <results based on inputs are calculated as described in a table>
The Given-When-Then detracts from understanding and readability but provides the much prized automation through tools like Cucumber and sister products like SpecFlow.
The tragedy of Given-When-Then: Act II
A common anti-pattern with Given-When-Then has the Three Amigoes collaborating on scenarios that are stored as acceptance criteria in user stories. The tester then translates these Given-When-Then scenarios into Cucumber format feature files. This occurs in parallel to development rather than ahead of it. The reduction of the tester to an expert translator/typist is a tragedy. It means that the business analyst does not necessarily see the actual Given-When-Then statements and a disconnect occurs between the them and the testers and developers. Cucumber comes to be seen as a test automation tool rather than a repository of the system specification.
The tragedy of Given-When-Then: Act III
The disconnect between the business analyst and the testers/developers is reflected in the Given-When-Then community. Business Analysts often do not see the feature files and do not fully understand the process. They see no value in cucumber, seeing it as a test automation tool.
The result is a void.
To fill this void developers create processes that appeal to developers because they tell the business analyst how the developers think the business analysts should do their jobs. Event Storming and Example Mapping are popular for training courses and conferences. They are fun, active facilitation processes. They are easy to learn and obvious, creating complex outcomes. They also fail to meet the needs of business analysts who by their very nature operate in the complicated space of documenting and defining complicated systems. Business Analysis requires the application of structured learning techniques that require study and practice to master.
The tragedy is that Given-When-Then has created a bigger void.
Agile was created by studying those who “do it and help others do it”, except in the case of business analysis where developers make stuff up for business analysts to do… Where the observers, not the doers, define the process.
The tragedy of Given-When-Then: Finale
Ideally we will realise that Given-When-Then is a tool for describing the interactions, state and behaviour of systems. We will realise that describing data and calculations using the Given-When-Then format leads to tragedy, and will create and popularise tools and approaches using Excel to document examples.
The Given-When-Then community will reach out to the business analysis community and listen, listen to their issues, listen to their needs. They will discard their pre-conceived solutions and collaborate to create tools that bridge the communication gap between business analysts and development teams.
When we have more than a hammer, we will see that the world is made up of more than just nails.
Acknowledgement: This post was inspired by an e:mail discussion about cucumber. The discussion helped me realise that Given-When-Then is as much of a hindrance in some contexts as it is a help in other contexts.
