Sun, 25 Jun 2006
I have a client that has many, many mainframes. Every project I might coach involves mainframes to a much greater extent than I've experienced before. I'd like to help the mainframe people with their programming and, especially, testing. If anyone has experience reports for me to read or stories to tell me, please do. I've already ordered Agile Database Techniques and Refactoring Databases.
I will set something up on the topic at Agile2006, both in the Open Space sessions and in the Agile 2006 Fringe (to be explained later).
This week, I gave seven (!) presentations of a live demo of testing and design in an Agile project. I started with a product director's idea for a story; showed the business-facing tests used to nail down that idea for the programmers; demonstrated how a programmer can use testing to make every step a small, safe, checked one; and ended (in some versions) with a working feature to be demoed and then manually tested (in an exploratory style). The idea was to get across a gut feel for how development feels, plus show some key principles in action.
Here's something that really came into focus as I (at first) kept radically changing the presentation and (later) tweaked it:
I expect product directors to read these documents collaboratively, sitting down with at least one programmer or tester. So the product director has to be semi-comfortable with the notation. (I also like it if that notation lends itself to looking at the feature in a different way. For example, a tabular notation for state machine designs encourages you to think through more cases than a node-and-arc notation does. That's also why Fit tests are good for business rules.)
So we want readability by a non-technical audience. However, the need for the documents to be executable pushes the notation in the direction of the product's implementation language.
It's balancing those two forces that's the trick.
There are two other sets of forces to balance:Fragility vs. comprehensiveness
The more detail there is in the test, the more fragile it becomes. That means a change to a single fact about the program will break many tests, and the breaking of a particular test may tell you nothing new about the program. That's wasteful.
And yet, detail that is not tested may not be gotten right in the first place. If it is right, but then goes wrong, you may well not notice it.
Excess detail seems to cause the most problem in the user interface. Today, my solution is to have the tests describe intermediate results from user-experience design (as I have glancingly learned it, mainly from Jeff Patton). Today's two types are:
I sometimes refer to myself as a "recovering abstracter." I used to jump to abstractions way too fast. Now I believe in building them gradually by implementing examples.
Neverthess, abstractions are important. In many programs, the real value comes from the business logic. Those are abstractions (of what's already worked for the business, I hope). All of my tests above abstract out detail. More importantly, the story of a project's ubiquitous language is one of developing shared abstractions.
But the majority of business people, it seems, are not practiced at thinking in abstractions (at least, our kind of abstractions). Notoriously, they want to see the user interface right away, they want it to be pretty (that is, detailed), and they want to talk in terms of what's on a screen rather than the concepts behind it. Their desire to do that conflicts with our desire to abstract away fragile and confusing detail.
We need to strike a balance. Over time, we need to show them that they can get what they want from us more easily if they tolerate our need to write things down in wierd and hard-to-visualize notations. (It worries me that I don't see what we're giving up in exchange.)