December 11, 2013

...Learn TDD with Codemanship

Don't Just Eat Your Own Dog Food. BE THE DOG.

Imagine you had to explain how you do your job to someone who's never written a line of code. Now imagine that they're tasked with designing an IDE for you.

Yes. The horror.

How could we possibly expect someone who's never been a programmer to design good programming tools? We can't. It would be madness.

Madness, too, to expect someone who's never worked the tills in a supermarket to design a good Point of Sale solution, or someone who's never balanced the books to design an accounting package.

Domain knowledge is the flipside of craftsmanship. You cannot hope to satisfy needs you do not understand - except by sheer blind luck.

The traditional approach of the software industry to understanding our customer's needs is to sit in a room - possibly with biscuits, if you're working in one of those posh organisations - and talk about it.

So, imagine again sitting in a room with someone who has never written a line of code, talking about how you write software. Nope, still doesn't work, does it?

Writing software is a complicated business. We couldn't hope to articulate all the minutiae, no matter how much coffee and biscuits we can bring to the task. And, it turns out, some of those minutiae are kind of important. We may not think to explain them, just as a guitar player may not think to describe all the different ways she might need to use the pick on a single piece of music.

Most work is crammed full of tacit knowledge. This is a question of consciousness. Describe all you like how your job works, but the listener will never understand what it is like to be you doing that work. I've worked on tills during my student days, and there's more to it than whoever wrote the software for them obviously knew. Which is why we often see till operators fighting against the software to get the job done.

Actors have this approach they call "The Method". When Method actors want to really get into a role, they experience what it's like to be that person first-hand. If they're going to play a cop on the mean streets of, say, Tunbridge Wells, then they undergo some police training and spend a few nights on patrol with experienced officers to discover what it's like to be those police officers.

We can learn from this. I would always recommend that developers eat their own dog food, and invest considerable time using the software they've written so they can see for themselves where the problems might be. But I believe we must go further. It's not enough that we eat our own dog food. To truly understand our customer's needs, we must be the dog.


This is why I now recommend that teams begin development not by talking about requirements, but by immersing themselves in their customer's world - at least where it surrounds the software they're thinking of building - and experiencing first-hand the workflows and business scenarios that the software is going to be used in.

If these jobs currently don't exist, I recommend simulating them as realistically as possible. You are creating a new world, and that should start with imagining what that world might look like. Sure, the world will evolve, but it's simply not enough to rely on the spoken word and a few box-and-line scribbles to build a rich enough picture to inform what we do.








Posted 4 years, 1 month ago on December 11, 2013