Fully Engaged by Example

First, a personal note. I'm feeling fully engaged. You know that feeling, when it seems like what you're working on occupies 100% of your attention, when you have to fight to think about anything else.

This weekend I went climbing in Kentucky. On Saturday night I was at a rocking party with some of my most attractive friends dancing up a storm. I was in a corner, writing down thoughts about how my project would help people communicate about software functionality using examples. And I love to dance!

Sometimes a dance is just a dance, but an idea is a dream coming to life. I didn't want to miss the moment. Do you ever feel like the entire Universe is conspiring to move you forward? It isn't really, but it feels that way because you're so positively attuned to your idea that you can find help from even random outside events.

And after a weekend working on examples, what do you suppose I spied on a church billboard driving home?

Okay, now about examples. Here's the pain point in development. How do we communicate about what we're going to build and why over the life of a project, not just in version 1.0?

Jonathan Edwards does a terrific job of explaining the problem:

Programmers in the real world will tell you that specs aren’t worth the paper they are written on. They are half-baked informal descriptions that are too abstract to be understood by the users, and too imprecise to be useful to the programmers. They are full of internal inconsistencies and factual errors, because there is no way to test them. They are obsolete the day they are published, because it is too difficult to rewrite them as the system becomes better understood. Things are no better with the other standard commodities of development: project plans, schedules, cost estimates, and documentation.

Jonathan Edwards, The Currency of Development

Jonathan is trying hard to build mechanical ways of getting teams to work together. Have a look at his ideas: he's an original thinker. I'm interested in a slightly different take on the same problem. As he puts it, "They are obsolete the day they are published, because it is too difficult to rewrite them as the system becomes better understood."

How do we make it easy to rewrite functional specifications? Some cultures try to solve the problem with command-and-control ("thou shalt not make a code change without an accompanying tech spec").

What I've observed is that all the information we want is out there in emails, PowerPoint decks, screen shots, and documents. And that's just the stuff produced by customers/analysts/product managers. What about the comments in the source code and the source code control system that describe how the changes close a specific bug or implementa specific feature?

Everything's fragmented and gets more and more unwieldy as projects move forward.

Using examples as the central communication idea is just part of the solution. We need to make it easy to write examples and read them. We need to track the history of changes. And we need to tie the examples closely to tasks and releases.

Labels: passion

  ¶ 1:43 PM