The stars shone brightly

I went to my first Tai Chi class tonight, something I've thought about doing since I was at university and saw a group of Chinese students practising. The smooth flowing rhythm of the movements was both relaxing and invigorating, quite an antidote to the physically sterile nature of much of the work I have been doing recently. When the class was over I took a moment outside to gaze up at the beautiful stars overhead, and I could smell the spring hyacinths nearby, and I felt at peace.

Q: What is a coach?

This is a question that I thought I had a good answer to. Now I'm not so sure. (It doesn't help that much of my original answer boils down to "coaching is the name I give to the thing(s) that I do".) I first felt unsettled as I read what Bill Caputo had written in an email: "Coaching is -- XP or otherwise -- about helping the entire team, define, understand, and improve the practices and processes of that team. As such it is a leadership position -- and also on the ground. I have said more than once, that the best coaches coach by achieving excellence in the practices they are teaching, and living those practices while working on the team -- including and especially the practice of pairing, which is the most effective way they can transfer their knowledge. More evidence that leadership itself is an activity and not synonymous with one's job description".
Could it be that what I call coaching is what other people call leadership? I'm not sure: leadership and coaching are definitely related, but while an effective leader can certainly be inspiritational, the "coach-as-inspirational-example" model seems to be missing something important. But I couldn't pin down what it was at the time.
Anyway a month or so after that I met up with some of my colleagues to discuss whether coaching really is 'just' an activity, and that led to more of a debate about exactly what it is a coach does, or can do (distilled here by Alan Francis). After the dust settled it seemed to me that some people were only interested in discussing coaching in terms of an activity that is done to other people. (The "coach-as-teacher" model.)
Whereas I see coaching very much as an activity that is done with other people, in order to bring about transformations in modes of thought and behaviour. This has become clearer to me as I have been reading up about a guest speaker who is coming to ThoughtWorks to talk about her (executive) coaching work.
This page for instance says: "the need for coaching comes from the absence of true conversation in the workplace" and "genuine human presence is the most subversive and creative thing. As a coach, be present in a way that speaks to the secret subtext of [the client's] potential". This definitely sounds more like the level on which I want to engage...
I'm sure that I'll be posting more on this topic in the future.

Double-entry book-keeping for software systems

As "enterprise" software grows in scope and scale it becomes harder to keep track of all the transactions that are created. At a certain level of complexity - say high volume work flows containing parallel or time-delayed steps - I think that it makes sense to introduce a double-entry book-keeping approach. Doing so makes it easy to aggregate completed transactions (and the effects of those transactions) and to identify and isolate incomplete transactions - just as accountants do with financial transactions. And it is certainly easier to reconcile between (or across) multiple collaborating systems if you can treat the transactions flowing between them as credit and debit entries that offset each other in a virtual ledger. (This post was prompted by the interplay between comments made by my colleagues about the desirability of queue-based / event-driven architectures, and the problems I have encountered trying to reconcile messages sent between intertwined sales and stock systems.)

In what way is software development an academic subject?

A UK university is offering students the chance to study for an MSc in agile software. Now I know that this question is almost as old as software development itself, but it what way is software development an academic subject? While I concede that classroom teaching has its place I think that a hands-on approach provides a better framework for CompSci students to appreciate how agile methods address the real-world pitfalls of application development. (BTW Richard Gabriel's proposal for a Master of Fine Arts in software development has a lot to recommend it too.)
I feel quite strongly that proficiency in software development requires a significant amount of experiential learning. Each combination of team, technology and client that we encounter provides an opportunity for us to grow professionally and personally. (And this is a strong argument in favour of the Apprentice-Journeyman-Master model of Software Craftsmanship.) But how many job ads do you see where "significant diverse experience" is seen as an advantage, or even a pre-requisite?
In the continual rush towards 'the next big thing' - a rush that favours the optimism and energy of youth over the caution and steady pace of experience - the software industry seems to embody George Santayana's prediction that, "Those who cannot remember the past are condemned to repeat it." (Apart perhaps from in the *nix / hacker culture, where there is a sense of history, and older heroes can still be role models.)
Postscript: This article by Pete McBreen passionately makes the case that software development is not something that can be easily taught or learnt. In the end, it comes down to the fact that you learn to be a software developer by actually doing software development. Toy problems don't count. What you have to do is work on a project you care about—one that you become passionately interested and involved in. Once that happens, you'll discover that you can learn whatever you need to learn, and that learning a new programming language, while a time-consuming pain, is really quite easy.

Motivation = Meaningful work + Worthwhile goals

Is it unusual to believe that the best software development jobs aren't necessarily the best paid? I have never seen an employer successfully motivate a software team solely with better pay (though I have seen an employer demotivate a team with 'secret' pay differentials that failed to reflect skills and responsibilities.) I find it useful to reflect on the tension between the desire to earn more money and the satisfaction I already get from the work that pays my salary, especially at a time when the IT job market seems to be picking up and agencies are keen to attract attention with high headline salaries.

As Stever Robins of LeadershipDecisionworks Inc. wrote: You want people emotionally invested in the company's success. You can get that investment by giving them meaningful work in service of a worthwhile goal. Hire people who believe in what you're doing and match them to jobs. If you want to reward their commitment, then give them stock, but make it crystal clear you're rewarding their innate involvement, not trying to buy it.