September 27, 2006

...Learn TDD with Codemanship

Tactile Modeling

People have been creating informatons systems for as long as recorded history (which goes without saying, I suppose). Long before we PEEKED or POKED or GOSUBed our way through life as computer programmers, the representation, storage and manipulation of information had been mastered by what we now laughingly refer to as "non-technical" people.



On Agile teams, we often use simple paper-based information systems to plan and track our projects. The core of an adaptive planning system is the story card. Each card represents some feature of the software that the customer wants us to deliver. It has a title, an estimate and a brief description. Some teams put little coloured stickers on each card to denote progress. Usually this mimics a simple traffic light system where RED means that the work has been started, AMBER means that the feature is ready for customer acceptance testing, and GREEN means that the feature has passed the acceptance test and can be counted as complete.

Some teams also keep records of roughly how much time was spent on each story and by whom. This helps track rough costs for each story, which can be useful in metrics, reporting and especially budgeting.

Some teams attach written acceptance tests scripts to the cards using paper clips. Others break each story down into engineering tasks, and attach those or put them all in a shared plastic folder to keep them together.

Many teams keep the cards in boxes, and often the cards are kept in the order determined by the customer in planning sessions. These represent queues of story cards.

However we look at it, these are information systems. And if you asked me to build a planning tool for you, I wouldn't struggle to understand the domain because I can explore it in the most visual and tactile ways using real story cards, real stickers, real paper clips and plastic folders, and real card boxes.

One of the pitfalls of traditional analysis and design techniques is that we often rely on user interface prototypes to communicate the requirements, which is rather jumping the gun. Typically, the only visual language we share with the users is the language of the UI - windows, dialogs, text boxes, buttons and so on. But by describing functionality in the language of the solution, we miss a critical opportunity to fully understand the problem before we commit to a UI design. The consequences can be dramatic: clunky and half-baked interfaces stretched awkwardly around lumpy, inelegant domain logic.

If only we could explore the domain and the functional requirements without committing to a design in the process. Well, we can. All we need to do is create an information system as tangible and tactile as the adaptive planning system, specific to the users domain. So if we want to model a DVD library system, then let's get a bunch of DVD's (or some pictures of DVD's if budgets are tight), some boxes, some cards, some stickers, some paper clips, folders, string, sticky-back plastic, and whatever else we think we might need to make a physical information system that will actually do what we need.

After all, if we can't get it to work on paper, how can we realistically expect to make it work on a computer? And besides, there's always a chance we'll end up creating a working system and realise we never needed to build any software in the first place. It certainly turned out to be the case for adaptive planning!
Posted 14 years, 3 months ago on September 27, 2006