Exploration Through Example

Example-driven development, Agile testing, context-driven testing, Agile programming, Ruby, and other things of interest to Brian Marick

191.8

⇒

167.2

⇒

186.2

183.6

184.0

183.2

184.6

Mon, 06 Mar 2006

Article on getting started

One of the things that interests me is how a team gets into alignment with its Product Director (sic). The path is often rocky, especially with someone who's never been a Product Director before.

Something I hear a lot of complaints about—and have griped about myself—is Product Directors who are too attached to the UI:

• They describe stories in terms of the UI they want to see. When the nouns and verbs that make up the business domain are tied to GUI elements, it takes longer for the programmers to understand those words in the way that works best—by encoding them into business logic and fiddling with them in response to new stories.

• Instead of being happy with a first draft GUI that's two text fields and a submit button, their stories include javascript input support and validation, they want nice-looking CSS, etc. That kind of work adds friction to the project; the necessary early flailing around is slower and harder when each change affects more code.

I think the cause is one part lack of experience, one part fear, one part necessity, and three parts reasons I don't know yet. The Product Directors are not used to talking about programs in abstract terms, in conversations where they're not pointing at a UI element but instead pointing at (say) nodes in business workflows. The fear is that crudeness of interface extends all the way down through the code, so that it represents everything being tackily done, not just the top layer. Will the programmers ever be able to put a good GUI on?

Those are (I claim) bad causes. The good cause is that the Product Director is the project's representative outward to the business. She will be showing the product to lots of people even more likely to judge a book by its cover, a product by its UI. A snazzy UI may be the path of least resistance.

Still, I think we'd be better off if we knew how to make a persuasive case for growing the UI as gradually as we grow the feature list. When the product is halfway to release, it should have half the features and half the UI glitz, not 1/4 of the features and all of the glitz.

If you have a track record at persuading Product Directors to hold off on the GUI, or if you have anything profound to say about any aspect of aligning the Product Director and the team^*, I'd like you to write me an article for the princely sum of US$500 and undying fame.

^* I don't want to give the impression that I think the Product Director does all the shifting of perspective and the rest of the team does none. It's not a matter of whipping the Product Director into shape. The alignment is a matter of trust going in all directions; I just happen to focus on having the Product Directors trust the programmers and process because lack of that trust makes it harder for me to get example-driven development going.

## Posted at 13:36 in category /misc [permalink] [top]