Continuing with my recap of the AYE Conference sessions I attended, I come to Johanna Rothman’s session, Choosing the Right Coaching Approach: Congruent Coaching. This was a time-slot where I wanted to attend every single session. I chose this session because coaching is a big part of what I do, and Johanna is one of the best people I know to learn to coach more effectively.

And my favorite “sound bite” of the session was Dee Fuellgrabe saying, “The client can do with the problem what he wants. He can also keep it.” What a great reminder that we, as coaches, cannot solve the problem for the client. We can only help the client become better prepared to solve the problem.

On last Monday afternoon, I attended the session, Remembering Your Resources When Stressed: The Self Esteem Toolkit led by Jerry Weinberg. This session dwelt on a idea Jerry borrowed from Virginia Satir. We have the capability to do the things we need to do, but we often forget our powers when we’re stressed. The toolkit is a set of reminders of the capabilities we have. Jerry has added to Virginia’s original list, and published them in More Secrets of Consulting.

The book includes:

• The Wisdom Box
• The Golden Key
• The Courage Stick
• The Wishing Wand
• The Detective Hat (and the Magnifying Glass)
• The Yes/No Medallion
• The Heart
• The Mirror
• The Telescope
• The Fish-Eye Lens
• The Gyroscope
• The Egg, the Carabiner, and the Feather
• The Hourglass
• and The Oxygen Mask

You can read about them in the book. I have; these are not new to me. I attended the session to remind myself more powerfully, so that I’ll remember these tools more readily when I need them.

And Jerry reminded us that we can add other tools to our toolbox, too. So I suggested The Ear Trumpet. This is to remind me to listen to what others have to say, and to really hear it.

Here’s a modelling scenario that crops up on many occasions in software systems.

Today is wednesday. The friendly neighbourhood HR person is updating the HR system. She needs to record the following information.

Last thursday, Bob from Treasury received a pay rise, commencing next friday.

It’s now monday almost 2 weeks later, the business day after next friday. Friendly neighbourhood HR person is told of a mistake with Bob’s pay rise. She needs to record the following information.

The pay rise recorded for Bob 2 wednesdays ago that he received 3 thursdays ago that commenced last friday was wrong. It should have been backdated to the beginning of the month, 5 fridays ago, not last friday.

Developers and their software can get in an awful mess if sufficient thought is not given to the many dimensions of time. In this example a robust system would have recorded the following:

• The time the initial entry was made by FNHRPerson.
• The time the pay rise was given to Bob.
• The time the pay rise took economic effect.
• The time the entry was modified.
• The new time the pay rise took economic effect.

It might also need to answer questions like, ‘when does Bob’s pay rise take effect?’ and ‘as of the day before yesterday, when did you think Bob’s pay rise took effect?’.

There’s a whole other side to this story with respect to calculating how much money had changed hands and the correction required in light of the new date data. But that’s another dimension altogether.

The AYE 2008 (Amplifying Your Effectiveness Conference) is now history. I never have time to blog about this conference during the conference–I’m always too busy. Besides, it’s so rich with learning that it takes me awhile to process it. This year (my fourth at AYE), I’m going to look back through my notes and blog a little about each session I attended.

The first session I attended was titled First Steps for Organizational Change: Unearthing the Data You Need and was presented by Johanna Rothman. I say presented, but like all the sessions at AYE, the word “presented” doesn’t convey the essence of the session. Johanna presented a lot of information, to be sure. (And you can find some of the same material on the AYE Wiki.) But the power of AYE lies in the fact that all the sessions are experiential. In this session, we took turns, in small groups, interviewing each other, and observing each other interviewing. And after each interview session, we examined the experience in a debrief. The debrief is the heart of the experience, for it’s where we make our actions explicit to ourselves. And it’s where we share our insights with others, and share theirs.

A few Johanna tidbits from my notes:

• Don’t be afraid to ask for quantitative data before starting an assessment, but don’t expect to get it.
• I take notes [when interviewing people as part of an assessment], but everything is off the record.
• Pay attention to differences between expectations and reality.

Thanks, Johanna, for a wonderful and rewarding session!

A couple of weeks ago, I taught Rapid Software Testing in Seoul, South Korea. I was there at the invitation of Wonil Kwon, executive director of STA Consulting. It was a professional operation in all respects. Mr. Kwon even brought in a team of translators to help. It was like the United Nations, with the translators in a small wooden booth and everyone wearing an earpiece. (I couldn’t resist saying “Dorsal Lateral Prefrontal Cortex” and “supercalifragilisticexpialidocious” a few times, just to give them a challenge. But the startling thing was to discover that there is no Korean word for “coverage” or “oracle.”)

Turns out there is a substantial South Korean testing community, and Mr. Kwon is a major player in it. Apart from outsourcing and consulting, he has written a few testing books, and teaches testing. Wonil also showed me some flashy online training. It was all in Korean, but done very professionally. The most interesting part, to me, is that he runs testing clinics. Clinics are cool. We need more of them in our industry. As I understand it, in each clinic, someone brings test documentation from a real project. The class then analyzes and comments on it.

I also discovered that he has organized an Asian testing alliance involving China, Japan, and Malaysia. Why haven’t we heard about any of this in the United States? Answer: little of it is happening in English. So, we in the U.S. and Europe must to work a little harder to discover the innovations and insights about testing that may arise in the Far East.

While talking to Wonil, I began to think that there may be distinctive schools of testing in the East (or styles within schools) that differ from the prevailing testing cultures in the West. I teach testing as a sort of mental martial art. Perhaps there is a “Tae Kwon Do” of testing practiced particularly in Korea? I want to look deeper into it.

TechnicalDebt is a very useful concept, but it raises the question of how do you measure it? Sadly technical debt isn't like financial debt, so it's not easy to tell how far you are in hock (although we seem to have had some trouble with measuring the financial kind recently).

Here's one idea to consider. When a team completes a feature ask them to tell you how long it took them (the actual effort) and how long they think it would have taken if the system were properly clean. The difference between the two is the interest of the technical debt. (So if it actually took them 5 days but they think it would have taken them 3 days with a clean system, then you paid 2 days of effort as interest on your technical debt.)

There are certainly some serious flaws with this technique. The statement of how long it would have taken on a clean system is an estimate based on an imaginary state - so is difficult to make objective. There's the effort in capturing this information, which is easy to get out of hand. But the result may help project a picture of the state of the code-base in a way that's visible to non-technical staff.

Furthermore it may also help with decisions about whether to pay the principal. Some teams like to add technical debt stories to their product backlog - with estimates on how long it would take to remove them. Such technical debt stories are also estimates, but also provide a picture of how much debt has built up. You could get a bit more clever with the estimated interest payments by apportioning them to these debt stories (I spent an extra day on this feature because of the bad state of the flipper module). Comparing interest payments with the principal may help inform a decision about whether to pay off the principal.

I ran into someone recently who tried something a little like this and found it handy, but it's not something I've run into a lot. Certainly there are flaws with doing it - but it may be worth a try for a few iterations.

The world of testing is divided into camps. Those camps argue with each other, sometimes. Mostly they ignore each other. These camps are like religions of software testing. They are determined and persistent patterns of belief, speech, and behavior. They could be called paradigms. In my community, we call them “schools.”

I didn’t create the schools (only the members of each school can do that) but I helped make labels for them. The labels represent these persistent patterns. Paul Gerrard wants them to go away. This puzzles me. It’s like trying to make culture go away. You can ignore cultural differences, of course, as long as you only work within one culture. You can ignore cultural differences if you wish to remain ignorant and provincial.

I’m a pluralist. I have my own testing religion (the Context-Driven School), but I recognize that there are others in the world. Besides Context-Driven, I share the world with adherents to the Factory School, Quality Control School, Analytical School, and Test-Driven Design School, and I share the world with people who form their own schools drawn from each of the other ones.

Paul suggests that no one wants to be a member of a school and that the schools don’t align to real-life testing. Paul’s wrong about that, and profoundly so. Actually the only people NOT a member of a school are those who have no beliefs or ideas about testing. But if you test, you must have beliefs about testing. You have a vocabulary and a sense of the tasks that are to be completed. As you gain experience and education, your beliefs (and consequently your actions) will exhibit an increasingly definite pattern and that can be observed and studied. It may be, as you learn, you change your beliefs. It may be that your beliefs are contradictory, at times. Still, as you get your head together about testing, a pattern emerges. That’s what it means to “know how to test.”

It’s true that the labels I use for schools are stereotypes– if that means a generic pattern. They are useful generic patterns, because they allow me to more efficiently characterize someone’s testing practices. I can say “that’s a factory approach except for this part, here.” People who study culture do use pattern languages to aid in discussing them. This is not some crazy idea of my own.

Paul Gerrard has written quite a bit about testing. He has expressed specific ideas and his ideas stand in contrast to alternative ideas. For instance, he has argued for quantitative risk analysis in test planning, independent of project context. That attitude is consistent with both the Factory and Analytical School ways of thinking, both of which extol the trappings of science (e.g. numbers). The Factory School way is to apply numbers without worrying about whether they have a rational scientific foundation (based on my arguments with Paul, he seems to be in that camp). Factory schoolers are keen to remove the icky human element from testing, wherever possible. They are annoyed by touchy feely things such as their own human infirmity. The Analytical School way is to limit themselves to laboratory contexts where the numbers apply or trying to change projects to ft the assumptions of the numbers. Analytical schoolers are generally academics.

I have debated quantitative risk analysis with Paul Gerrard. He certainly has different beliefs and ethics about numbers than I do. Without making a claim about who is right, isn’t it reasonable to say that he and I belong to different schools of thought?

People don’t necessarily sign up for these schools. Someone could describe himself as “spontaneous and care-free” without joining a club, or committing to that way of being for all time. Similarly, I could describe someone as “methodical and studious” even if he saw himself as spontaneous and care-free. I am not forcing anyone to join an organization by describing them according to a pattern of behavior. Schools are not necessarily communities or organizations.

In the case of the Context-Driven School, there is a community. At least one: mine. You can be context-driven without being in my community, but if you are context-driven in your behavior (meaning, in short, that you reject best practices and study skills and contexts instead) then you will probably be happy to join the software-testing forum at Yahoogroups.com. That’s the forum for our community.

When we began to declare testing schools, almost ten years ago, what we hoped to do was to foster a more scientific community. In science, the notion of schools is well-established. Since the time of the ancient Greeks, this has been so. By failing to establish this in the testing industry, we foster endless unproductive debate based on the assumption that we all share one foundation. In fact, our differences are very deep. There is not even a consensus, in the testing industry, about what “testing” means!

A few years ago I was talking with a client who told me something he didn't like about the agile approach we were using: "it's doesn't feel right to have these difficulties this early in the project". Contrary to his reaction, in my mind this early pain is one of the great benefits of an agile or indeed any iterative development process.

I have many complaints about the waterfall process, but probably my greatest problem with it is how it tends to defer discovery of problems till late in the project, at which point there's little time or energy to deal with them effectively. Iterative cycles try to flush out as many problems as possible as early as possible. This gives you more time to cope, or at least raises the problems early enough to cancel before investing too much money and effort in a problematic project.

A useful exercise is to reflect on past projects and think about where problems cropped up late. Now ask yourself how you could make those problems crop up earlier. The more pain you get earlier, the better.

Neal Ford and Rebecca Parsons will be working with me again on a DSL tutorial at QCon San Francisco. Rebecca and I will do a keynote.

My last scheduled talking arrangement this year is to return to QCon San Francisco. QCon is a organized by the JAOO team and organized in collaboration with InfoQ. It brings the conference formula that I like so well from JAOO to the US.

I've got two talks planned. One is an all day tutorial on DSLs with Neal Ford and Rebecca Parsons. This tutorial is the one we've done at a number of JAOO/QCon conferences in the last year.

The second talk is a keynote with Rebecca on the relationship between agile thinking and enterprise architecture groups. In our work we often have to bridge the gap between our approaches and somewhat traditional enterprise architecture teams - and Rebecca is usually working right on that boundary. So this talk brings our thoughts on how enterprise architecture fits in with an agile mind-set.

Oslo is a project at Microsoft, of which various things have been heard but with little details until this week's PDC conference. What we have known is that it has something to do with ModelDrivenSoftwareDevelopment and DomainSpecificLanguages.

A couple of weeks ago I got an early peek behind the curtain as I, and my language-geek colleague Rebecca Parsons, went through a preview of the PDC coming-out talks with Don Box, Gio Della-Libera and Vijaye Raji. It was a very interesting presentation, enough to convince me that Oslo is a technology to watch. It's broadly a Language Workbench. I'm not going to attempt a comprehensive review of the tool here, but just my scattered impressions from the walk-through. It was certainly interesting enough that I thought I'd publish my impressions here. With the public release at the PDC I'm sure you'll be hearing a lot more about it in the coming weeks. As I describe my thoughts I'll use a lot of the language I've been developing for my book, so you may find the terminology a little dense.

Oslo has three main components:

• a modeling language (currently code-named M) for textual DSLs
• a design surface (named Quadrant) for graphical DSLs
• a repository (without a name) that stores semantic models in a relational database.

(All of these names are current code names. The marketing department will still use the same smarts that replaced "Avalon and Indigo" with "WPF and WCF". I'm just hoping they'll rename "Windows" to "Windows Technology Foundation".)

The textual language environment is bootstrapped and provides three base languages:

• MGrammar: defines grammars for Syntax Directed Translation.
• MSchema: defines schemas for a Semantic Model
• MGraph: is a textual language for representing the population of a Semantic Model. So while MSchema represents types, MGraph represents instances. Lispers might think of MGraph as s-expressions with a ugly syntax.

You can represent any model in MGraph, but the syntax is often not too good. With MGrammar you can define a grammar for your own DSL which allows you to write scripts in your own DSL and build a parser to translate them into something more useful.

Using the state machine example from my book introduction, you could define a state machine semantic model with MSchema. You could then populate it (in an ugly way) with MGraph. You can build a decent DSL to po