December 10, 2014

...Learn TDD with Codemanship

Make It Real

One piece of advice I give teams on the subject of exploring customer's requirements is "Make it real".

Far too much time is wasted sitting in meeting rooms talking in the abstract, drawing pictures from memory and generally waving our arms around instead of getting a good hard look at the real thing.

There's no substitute for seeing it for yourself. Better still, doing it for yourself.

This works as much with code - our own problem domain - as it does with banking or TV or healthcare or whatever business problem we happen to be working on. Don't sit in a room and have a discussion about, say, the architecture. Bring in a laptop with a copy of the code, hook it to a projector, and look at the code.

Making it real cuts out a lot of the crap, short-circuits a mountain of unnecessary, lossy and often misleading exposition about the way things are, and enables us the chance to explore ideas in a practical way.

The main reason why so much software fails to deliver value isn't because we didn't spend enough time agreeing goals, or because we didn't spend enough time drawing boxes and arrows, or because we didn't have executable acceptance tests. The main reason so much software fails to deliver value is purely and simply because we didn't understand the problem, and traditional analysis techniques have failed to bridge that gap.

This is why, say, legal case management software written by lawyers who happen to be so-so programmers can turn out to be of much more value than legal case management software written by dedicated expert programmers who just happen to be working in law firms.

Of course, in ideal world, we'd have dedicated expert programmers who are lawyers. That way, our valuable solution might be reliable and maintainable enough to be a long-term valuable solution.

Domain knowledge is key, but most of it is tacit, complex, ambiguous, and gets lost in translation, and the people who know the domain better than anyone else are the ones who live there. To gain the necessary domain expertise to really solve a problem, we need to live there for a while, too.

Software solutions should begin with us immersing ourselves in the problem. We need to soak up all that complex information that only being there and doing that can convey.

The right environment for understanding the requirements for a trading application is not a meeting room with a couple of whiteboards - frankly, it doesn't matter how much whiteboard space you've got. The right environment for understanding the requirements for a trading application is a trading environment. Ditto a patient management system is best understood by managing patients, and a newspaper delivery system is best understood by delivering newspapers.

I continue, year after year, and mostly in vain, to strongly recommend that teams build what we call a "model office"; a dedicated analysis and testing environment that - as faithfully as possible - recreates the real world problem domain in which our software is intended to be used, so we can play out usage scenarios, try out ideas, show each other what we really mean when we say "the user does X", and test our software in a context that has meaning, and allows us to really ask the question "but will it work?"

And year after year, teams ignore the advice, and carry on down the sitting-in-rooms-talking-about-user-stories-and-business-goals-and- drawing-pictures-and-writing-cucumber-tests route that has proven largely fruitless these last 7 decades when it comes to creating software that solves real problems in the real world.

With a new year almost upon us, though, it's time again to dish out that advice. So, for what it's worth, here it is:

Make. It. Real.




Posted 1 week, 5 days ago on December 10, 2014