People ask me how to describe AYE. It describes itself as “a conference designed to increase your effectiveness in leadership, coaching, managing, influencing and working in teams.” My own personal effort is “It’s the world’s only touchy-feely software conference.” Which is true, but doesn’t go into the central (and surprising) concept of AYE: you are supposed to get to know the people around you, as people.

In normal conferences, one person stands on a raised pedestal and pontificates, and everyone sits and takes notes. In AYE, you sit in a circle and one person faciliates. That is, one person (with decades of experience) will ask people around the room what they think, and what their experience has been with tough situations. What their attitudes are. And how they feel. It’s sort of a cross between a brainstorming session and group therapy. I suppose that’s why it’s limited to 150 people.

This has a very democratic feel to it, and it makes you far more aware of the various personages around you as people. I once saw James Gosling, in JavaOne, walk past rows of fans looking for handshakes and autographs. By contrast, Jerry Weinburg will ask if he can sit at your table and tell you stories about the APL and PL/1 programming teams.

I was very confused the first time I went to the conference. I didn't know who these people were, or what they were doing. The first sign of learning is knowing that you're clueless. At AYE, I felt like a newbie. Everything was so jumbled that I didn't even know what I had learnt. But several months later, some of the things that I remembered from AYE were very useful. So I went again.

The first session I went to was interesting but I wouldn't call it a success. It was a session about capturing requirements, but the flow of information was very much down rather than being distributed through the group as a whole, and I thought that some of the exercises were too unrealistic to be taken seriously as an analog for software development. More to the point, I wasn’t sure I agreed with the faciliator: he said that he’s never seen top down requirements implemented successfully, and not only have I seen it, I’ve done it myself. So that didn’t go well. But I did learn something from it.

There was an anecdote the facilitator told about his wife, a vet at a school. One of the standards for judging whether an animal is sick or not is to ask whether it is “bright” or “dull”. Students will learn what the meaning of bright and dull means through repeated trial and error (bright means roughly “everything an animal is supposed to do” and dull meaning “not doing what it should”). Eventually, the vet and the student will be able to look at any given animal and determine whether an animal is bright or dull. But they will be unable to articulate what data led them to this conclusion.

There is an obvious analogue to anyone trying to implement a system: the business users of a system will tell you that the old system is dull. And they want the new system to be bright. But they will be unable to tell you how and why, in much the same way that a fish has difficulty describing water.

Lunch was interesting. There was a four year old there, the youngest person I saw. One guy had brought his wife and kid over, and he asked me for my experience (given that I’d been last year and must have seen something worthwhile in it). So I tried to explain as best I could.

And then Ruby on Rails was discussed.

I know Aaron is interested in Ruby, for good reason. I think that Ruby has a lot to offer and that in some ways it's a significant advance over other programming languages. But I don't think it's there yet. There is no decent IDE for Ruby. There are no commercial software libraries. Ruby doesn't support boring legacy systems like DDE or CORBA. Its performance characteristics are still widely unknown. And then there's the cold hard fact that Ruby doesn't do anything new. There's nothing I can do with it that I can't do already in Perl or Java, and I just don't find playing with new languages as fun any more. They are not major drivers in the success of a project, they don't solve the domain issues, and they don't provide any built-in facility for dealing with core recurring issues like persistence or transactions. Five years from now, Ruby will be more "standard" than Python or Tcl. But the next time I'll look at Ruby is when the next cool "Ruby-killer" language comes out.

The coffee was terrible, so Dave Smith drove out to Starbucks and got “real” coffee. Thank you Dave. I also got to talk to some people who had flown out from England for the conference and heard some scuttlebutt (Apparently Laurent Bossovit is “big in England” – a phrase I still find culturally disconcerting but there you go.)

After lunch, the second session was The Simplest Possible Thing To Amplify Your Effectiveness. I went to this session hoping for some simple things I could do to kick a project into gear. We were given a project to do with one third of the room evaluating, one third of the room testing, and one third building. Then we were asked for input into things we did that made it work. This didn’t work for me. The tips were too low level for my liking (“Make sure all the chairs are arranged in a circle” and “Bring a pen and paper” being two I specifically remember). So I left at the lunch break.

At which point, Earl E. asked what I was looking for. I described my situation to him and he suggested I sign up for the SHAPE forum as a way to get more of a dialogue. Earl also had some more insight into the conference: he described it as more of a “teach a man how to fish” event than a “solve this problem” event.

After that conversation, I retreated back to my hotel room to recover. When I came out and got to the bar, I found Erik M., Alan F., and Josh K. engaged in a conversation.

We went to the hotel restaurant and got to talking about Agile and Extreme Programming at dinner. Josh is the single best advocate I’ve seen for Unit Testing. He’s solid, sensible, understands the weaknesses and strengths of unit testing in different situations, and makes his decision to unit test not out of ideology, but because he – personally – derives benefit from it.

And then Jerry Weinburg came up and asked if he could join us. He regaled us with tales of the First Days of Computing and gave some useful feedback on the value of certification (he’s against it) and his experience with large corporations.

And then, it was time for bed.