I’m worried about Raja. Unless I do something drastic he’s going to die. In a rather messy and unpleasant way. Crushed by the weight of a 60 person-year software product.
But I think I’ve got a solution. Cucumber might well save Raja from his gruesome fate.
Background
Okay, that is a tad melodramatic – Raja is not actually going to die – but the underlying issue is real.
In a few months I’ll wind down my programme team and hand over maintenance of the system to Raja and another developer. These guys are the business as usual team responsible for maintaining and extending the system when the rest of the delivery team have gone. Raja and his colleague are good guys and keen but they will suddenly have responsibility for a system built by a team of 30 over two years.
The problem comes when Raja has to change code in an area of the product where he has not spent much time. Right now Raja can turn to one of the other developers for advice but post handover he’ll have to go it alone.
As the programme manager I’d like to leave Raja with a fighting chance of success in the face of a large and complex product.
Normal Handovers
A normal handover would involve some chats and some documentation. The person taking the handover has to learn the contents of the documentation or at least enough of it to know where to look in an emergency. The trouble with this approach is that documentation is passive, it just sits there until somebody comes looking, and it is almost certainly out of date.
Given the risk involved I decided to take a different approach to handover.
Cucumber
The core of my “Save Raja” campaign is Cucumber:
Cucumber lets software development teams describe how software should behave in plain text. The text is written in a business-readable domain-specific language and serves as documentation, automated tests and development-aid – all rolled into one format.
In other words Cucumber gives me requirements in English that are executable as tests. These Cucumber specifications replace much, but not all, of the normal handover documentation. That way I look at it, if we’re going to write something down about the system we may as well write something down that is an executable test.
Cucumber, along with the unit tests, has already proved its worth. One of my workstreams had to move their repository from Sharepoint lists to SQL Server. This rather daunting task took them only three days – pretty good really since the change broke the entire system. They changed the repository, watched all their automated tests go red, and then just worked through the tests until everything was green again. The tests were the developers check list of changes. The test suite also gave me confidence that they’d not missed something.
In a similar way Raja will benefit from having this test suite. He’ll know soon after he makes a change in development whether or not the change has had an undesirable effect on the system.
There are other benefits to using Cucumber including forcing product managers, developers and testers to talk, so I might have pushed Cucumber anyway. But my main motivation was to leave Raja a safety net so he can make changes with confidence.
The D-Day for handover is still a while away but at the moment I am confident that Cucumber will indeed save Raja. Or at least help.
Please comment if you’ve got other suggestions on how to “Save Raja”.