January 19, 2014

...Learn TDD with Codemanship

Customer-driven Development: How Our Dev Tools Forget The *Other* Team Member

Periodically I'm reminded just how bad we are at developing tools to be used in our own work.

Nowhere is this more obvious than in the clutch of tools that, in a sane and rational world, would be used by our customers and not by us.

Take deployment, for example. Deploying software should be the prerogative of the person paying for it. We make sure that it's always in a shippable state (right?). It then becomes a business decision to deploy the software when the customer thinks we've added enough value. So who should get to press the button? If deployment happens as a result of some command line hackery, then we've just taken the decision away from the customer. They have to ask.

Another example is customer acceptance testing; there are two places in this process where the customer ought to be in the driving seat, just as with deployment. First, the acceptance tests are theirs - in particular, the plain language versions of the tests (e.g., "Given... when... then...") and the associated examples (i.e., test data). So creating and managing these should happen using customer-facing tools. If you're one of those many, many teams who version control these acceptance tests using Git or some other VCS, then you've already failed in this respect. I've watched teams ask customer to edit and manage acceptance tests using Git and Vim. You can probably guess at the results.

The fact is, when we write these tools, we should be on the lookout for user stories that start "As the customer,..." and be mindful of their user experience as participants in the development process. Ideally, we could give them a joined-up experience, where their involvement is codified in maybe just one or two simple, intuitive tools. Presenting them with a mish-mash of domain-specific languages, Vim, GitHub, Jira and various other tools that even developers struggle with sometimes just doesn't cut the mustard. The upshot is that they tend to draw back from the process and disengage - the exact opposite of what we want to achieve, surely?





Posted 4 years, 2 months ago on January 19, 2014