Although CukeUp! has been running for a number of years, this was the first time I had attended. Hence, the usual nerves worrying about whether it will be a good event. It turns out that this is not only a good event, it is a great event that I highly recommend to all who work in IT. If you are concerned that it will be bogged down with endless discussion over Gherkins then do not be as the three tracks and associated workshops provided enormous variety.
A nod to the host, Skills Matter, is also warranted. They looked after us over the two days with aplomb, seemingly anticipating every point at which the munchies strike with snacks and food on tap (including a scrumptious breakfast on arrival). Having a host that genuinely cares about the people attending is a huge plus. It was one of the reasons I was so impressed with EuroSTAR 2014, for example.
Day one started with a keynote from Rachel Davies and Aimy Ko, “Breaking out of the pickle factory”. This was fascinating because of their immediate confession: they do not use BDD, working in an almost-pure XP house. Shock! An organisation promoting non-BDD techniques at a BDD event! This turned out to be a very good thing for two reasons: firstly it clearly demonstrates that there is never going to be a single methodology that suits every situation. Secondly, hearing a non-BDD viewpoint on delivering working software gave a good basis for comparison for the rest of the event, and I did find myself mentally referring back to that keynote over the two days.
As the event was split into a number of tracks with an abundance of good stuff on offer I clearly had to pick, and it was a tough choice. To start I opted for Richard McInture’s “Semantic BDD: Visualise your projects through features”. Working with BBC Sport Richard took us through their Should It? tool. Richard noted how the teams that he worked with tended to already have a good understanding of the background and pre-conditions for a scenario (let us all call that the “Given” and “When”) and wanted to focus on specific solutions to statements in the form “It should do X” (the “Then”). The worked example given was easy to follow and we could clearly see how using markdown to write feature files with the inclusion of rich media there-in could quickly be used to define a complex offering such as an eCommerce website. Richard focused part of the time on looking at how to define page pagination. It sounds like a simple problem to solve, but from past personal experience this is never easy as so many conflicting methods for doing this exist. Again, using markdown we could quickly see a mocked-up pagination system appearing on-screen. Best of all: Should It? is available for free download from Github. I was very impressed with Should It? and will be trying out this tool and way of working very soon.
Seb Rose then gave a though provoking talk on the #NoEstimates hashtag that has provoked such discussion and conflict in the industry recently. He described that this does not literally mean not doing estimates, but instead means not doing pointless estimates, or estimates based on or of the wrong thing. He made a very good point here and I wholeheartedly agree: we cannot know for certain the effort required to create something new (which, by its nature is what software development does), especially early on in a project lifecycle when requirements are only partially defined, yet teams always feel pressure at precisely this point to come up with an estimate. Worse, the estimate is challenged to be made lower, which can cause a team to react by pre-inflating their estimate to allow for this (I call this the “Scotty Principle” named after the way Mr Scott on the USS Enterprise would over-inflate his estimates to get the warp core back online). Seb detailed this bizarre situation with the aid of the Cone of Uncertainty (I feel this could also be named the “Cone of Certain Doom”). This was a very engaging presentation. Seb’s take home message is that we need to be aware of the situation in which we find ourselves in: #NoEstimates is a beacon for those rejecting worthless estimation and instead delivering estimates at an appropriate point and based on empirical data that can be relied upon. A thought from Seb: “When will we admit we will never get better at estimating?”
The next workshop I attended was entitled “Hypotheses and measures”, presented by Arti Mathanda and Adam Scott. To me, coming as I do from a science background, testing to me should be broken down into a series of hypotheses that are specific, measurable, and hence testable. This was part of the core message from Arti and Adam who got us to consider the need to define a set of measurable hypotheses that could be tracked post-deployment of a solution. This is an interesting point to consider: we write software, which is deployed, but then how do we know if it is a success? Sure, we can measure the number of bugs found in production, but that does not tell us about success, it only tells us about functional quality. We considered an imaginary aerial drone-based grocery delivery service: what specific measures of success can be identified to test success post-deployment? After some discussion we worked on two measures: repeat business (“We want 50% of customers to place a repeat order less than one week after their initial order”) and public relations (“Drones should not drop tins of baked beans on people from a great height”). The second may seem fanciful, but with the PR concerns over the use of drones and their safety at the moment we could see a headline of “Baked Bean Tin Kills Grandma” causing such a service to be shut down overnight. Discussing the need for working hypotheses with Adam I mentioned how I currently use elements of this technique with product owners to help teams understand the important of producing software that solves real-world problems (from which we can derive those specific, measurable hypotheses). I definitely learnt more about how to apply this in my day to day work.
After lunch I attended Paul Rayner’s “BDD skills you don’t even know you’re missing” workshop. Paul makes a superb point: with the adoption of BDD, teams can all too often throw away or forget about all of the good non-BDD techniques learnt over the years. This was a two hour crash course and refresher in a number of these techniques, focusing on solving end-user business problems in relation to overdue library books. We considered the stages of divergence, exploration and convergence in understanding and defining a business problem, event storming and working backwards from the problem that is to be solved to understand the steps and events that got us there, and the importance of sticky notes: easy to change, easy to visualise, and easy to put to one side when an alternative history is discovered that needs a product owner’s input. Sticky notes flew everywhere, with us constantly breaking into pairs, coming back into table-sized groups and then one large group. Paul described the workshop as a four hour session in two hours. I agree, yet it was in no way cramped or curtailed. This was intense, somewhat manic, and highly engaging. If you spot Paul running this session at any other event I highly suggest you go along.
For the last session of the day I chose “Taking back BDD” with Konstantin Kudryashov, creator of Behat (Behavioural Testing). This was an excellent presentation which considered the evolution of Gherkins in a team, using Behat and PHP to provide specific examples. When teams first start with BDD they tend to mix business logic with implementation which obscures the message for the business, and forces developers to constrain their implementation. The irony here is that the developer would have been the best person to have written the implementation design. Then, the pendulum swings wholly the other way and we find our scenarios missing the clues that help development understand the relationship between the problem and how to tackle it. Finally, the pendulum settles somewhere in the middle and a happy medium is reached. Konstantin mentioned that he understands Dan North to have originally meant for Gherkins to be written in this latter manner. I work for Capita IT Professional Services (@CapitaITPS) and my team has been through a similar transition in our Gherkin syntactic style. We realised the same problem and, by coincidence, came up with the same solution: the result is something that is readable by the business, tester and developer. Having said that, it is clear that the use of Gherkin will continue to evolve and Konstantin and I continued this conversation at the local pub in the evening of the first day. I’m working on something in this area at present, and gave a brief demo of this as a work-in-progress to a number of people over the two days and got positive feedback. That’s another great thing about CukeUp!. You can present your ideas pretty much at any time in the breaks in the full knowledge that you can get constructive feedback from product owners, developers, testers and business analysts all in one go. Konstantin’s message was clear: get enough information to describe a problem, but not so much that it prescribes a solution. Use a ubiquitous language to do this. Konstantin described this as Modelling by Example, where the same Gherkin scenario written to exercise business logic could be re-executed against the UI. He advocates initially removing the UI from scope and focusing on the domain layer where the business logic resides. When this is defined and the scenarios are passing, then bring the UI layer back in to play. Konstantin is clearly both a great practitioner and great thinker when it comes to BDD and software development as a whole and Modelling by Example is something I’m going to be looking to invest time in in the future.
Day two started with a keynote from Dan North, who presented an interesting view on the state of agile. As Dan puts it, “Agile was coined in the early noughties and then strange things happened.” One observation he made is that the Agile Manifesto has become flipped around, for example instead of “Individuals and interactions over processes and tools” teams talk about tooling the moment they consider agile, i.e.: “Processes and tools over individuals and interactions”. The same can be observed for the other Agile principles. Dan highlighted this point with reference to Inigo Montoya from The Princess Bride, who at one point in the story becomes highly frustrated with one of his companions who constantly describes the unexpected as “inconceivable” by replying, “You keep using that word, I do not think it means what you think it means.” His argument is that this has happened to Agile. This is an interesting viewpoint and certainly one that bears further consideration.
After the first break Matt Wynne took us through the move towards Cucumber 2. The code base appears to have been substantially re-written, resulting in a very clean and lean cucumber-core. To demonstrate this Matt executed a test suite on Cucumber 1 and we watched as it took about two minutes to complete. A comparable suite was executed on Cucumber 2 and took around 0.2 seconds to execute. Yes, Cucumber 2 is much faster. One interesting point arose here: Matt works on the Cucumber software each Friday and it is an open source project without a commercial deadline to meet. This has some parallels to the Slow Food movement, meaning he can consider appropriate solutions to problems without the hectic pace of being required to constantly deliver. He stated that this has given the team freedom to make some choices that would not have been made if there had been commercial pressures, leading to a better end product. Matt concluded by publishing Cucumber 2 live to the web for all to download and use.
I then opted for a session hosted by Megan Folsom, “The failed pet projects of powerful public figures”. This considered three projects from an outsider’s point of view: Google Glass, Amazon’s Fire Phone and the implementation of the website for ObamaCare, the colloquial name for the Affordable Care Act in the USA. Taking each in turn a consistent argument was made that the apparent lack of mass-market success for these three projects has been due to the wrong customer being identified, the wrong problem specified and the wrong solution implemented. The message presented was that each was created for the project sponsor, where-as they should have been created to solve the real-world problems of people in the street. We looked at how Gherkins could be written that incorrectly considered the head of these three projects as both the project sponsor and end-user when the two are clearly separate. Megan then re-wrote the Gherkin in each case to put the end-user at the heart of the solution. The message here is important: just by writing a scenario in Gherkin does mean success will be had if you write the wrong scenario for the wrong subject. Context can make or break your product / project.
Dan North’s “Software, Faster” workshop was always going to be popular at an event focused on BDD, but despite having an absolutely packed room he demonstrated great ability in including all in the discussion by bouncing around the room, presenting from the front, side and rear (“there is no back of the room”). We went through several exercises, the first being a question: “Does code have value?” There was a definite split in the room here with roughly 49% saying “Yes”, 49% “Sometimes” and the remainder (three people, myself included) saying “No”. My reasoning is straightforward: I feel the question is about intrinsic value and no, code has no intrinsic value (compare to money: a ten pound note states on the front “I promise to pay the bearer on demand the sum of ten pounds”. The value comes from what we do with the note, not the note itself). Dan furthered this argument by noting that if a given problem can be solved by either a complex or straightforward software solution then the more straightforward is likely to be the best choice. Taking this to its logical conclusion, the simplest software is zero lines of code, i.e.: if we can solve the problem just as well without as with software then why write software to solve the problem? This is why I believe software has no intrinsic value. Dan’s view in the workshop was that if organisational design can lead to solutions without software then the business capability is the asset because it has business impact. The software is not the asset. We worked through a number of group exercises leading us towards the consideration that, as Dan put it, “Software faster is about using software to better deliver business impact”. We considered that Discovery = Exploration = Analysis, the nature of first class work, that Discovery should be considered first class work (yet is mostly not considered as such in teams), and the problem of Analysis Paralysis (Dan prefers the term Analysis Dialysis). We looked at several different analysis patterns, investment inversion and risk adjusted return on capital as opposed to ROI. A lot to take in! This has direct relevance to working in a team using BDD as we have to consider that analysis and estimation is a continuous, ongoing process, and not a single shot at the start of an iteration (or worse, at the start of a project).
After lunch I attended a workshop entitled “Experiments with Flow – Learn how to get more done with less” from Tom Roden, Ben Williams and Chris Roff. The workshop took the form of attempting to maximise the flow rate of a system. For the purpose of the workshop we were presented with the challenge of shifting twenty balls around a group of people while adhering to some basic rules such as “Each person must touch each ball”, “you cannot give a ball to your direct neighbour”, and “you cannot pass, but must throw the balls”. I found myself nominated as Product Owner as I thought I had a good production line proposal, namely to split the team into two halves and run two balls concurrently running in opposite directions through a figure-8 loop. Sounds good, but it turned out to be horrendously complex for me to manage as I had to track four running counts: balls in, balls out, balls to the left of me, and balls to the right of me. Hence, I became the bottleneck. Our time came in at over three minutes to complete the task. One of the team, a guy called Matt suggested removing the figure-8, and I’ll be honest, I was wholly against this at first. But, we tried it and immediately halved our run-time, while noticing an increase in quality (less balls dropped). Kudos to Matt for sticking to his guns here. Graphs on a laptop provided real-time feedback of our progress in each iteration, and we could look to see and optimise the process we employed. Over about five iterations we reduced the run-time to under a minute. For myself, I learnt two important points: firstly, we lacked genuine product owners in the room (only a few had come to the event) and I can see those in this role gaining the most from this exercise. Secondly, there is a sweet spot in reducing WIP. The mantra to “drive down WIP” that I’ve historically come across is clearly a simplistic argument: at one point we rate-limited our work to a maximum of two balls in play at once. The net effect was no appreciable improvement in quality and run-times that were sort-of ok. But, and here’s the key point, this resulted in a team that was bored (I guess this is why adults tend not to play pass the parcel at birthday parties). For this scenario we found a WIP of 5-6 worked well. Any higher and the pressure on the Product Owner started to tell when I lost the count and knocked the box of balls over in my haste, which we can interpret as a reduction in the team’s quality and efficiency. We also made a significant change from iteration two to three: for our second run we decided to try to flood the system. I would pass balls in as fast as I could, regardless of what happened down the chain. For the third, and all subsequent iterations we changed from a push to a pull based system, where I would only feed balls in when asked. This naturally introduced variable rate-limiting governed by the team and not the Product Owner. Reducing the rate of assigning work to a team to gain a faster rate of overall throughput does seem counter-intuitive, but in this simple scenario it worked well. It would be interesting to run a software development project in the real-world where no work is ever assigned to anyone unless they ask for it.
The last session was entitled “WTF is BDD?” It is a good question. A panel aimed to consider if there is a single definition of BDD that can be applied. Curiously, the conversation mainly revolved around the question of whether BDD should be defined or not. It is an interesting point: by saying that BDD is a specific set of skills, practices and processes then it is constrained to just those things. Instead, by refusing to define BDD in these terms we avoid the trap of pigeon holing ourselves into one thing or the other and potentially preventing evolution and improvement (I’m paraphrasing). I’m half-convinced by this, but it is difficult to turn around to a potential project sponsor and not have a singular definition for the proposed methodology that the team will follow. This was an interesting debate and will no doubt continue.
As mentioned at the outset, with multiple tracks to choose from it was not possible to cover them all. Hence, apologies to those presenters who I have not named.
My first CukeUp! was intense, fun and a great learning experience. Of the various conferences and training sessions I have been to over the years it ranks up towards the top. I’ll definitely be back next year.
Hope to see you at CukeUp! 2016.
—
Colin Deady (@ethicalwebsites) is a Technical Test Manager at Capita IT Professional Services (@CapitaITPS) where he focuses on using BDD to solve real-world business problems. In his spare time he dabbles with the Raspberry Pi, creating curious robots.
