Everything good comes to an end, they say. It fits the JAOO 2009 Conference. Even though wish that JAOO had been longer, so that I could spend more time getting to know all the great and creative people there, I also realize that the time has come to start digesting and hopefully putting into use some of the ideas that we were presented during this three day conference.

In other words, with the ending of JAOO 2009 I hope new and better things will arise from it, directly or indirectly. Maybe a customer with a REST-oriented project will drop by, or maybe some of the new acquaintances in my network will be starting up projects and a collaboration could emerge. You never know…

First session of the day was a session held by Linda Rising on Guiding your personal life - “plan driven” or “agile”. The talk was about, among a lot of other things, the difference in the perceived benefits from drinking beverages containing caffeine and actual benefits of taking proper breaks and nap during the day. All this in relation to work. One of her main messages was that although we feel better and brighter from drinking coffee or coke, is has significant impact on how we think, which in the end has drawbacks on the work delivered. Furthermore, it was the message that we as humans are not made for using our energy in a linear fashion 8 hours a day, but more in pulses, where we first use energy (for example in a 90 minute pulse) and then take a proper break to get new energy. This, of course, opposed to just continuing without a break and keeping fatigue away by drinking more and more coffee. Her statements were followed up by test results made on groups of people, and showed the difference in how things learned were internalized.

I most definitely could relate her message, as I’d say I’m very much a person who needs time to take new information and consume it by not working with it directly. I have to let it sink in. And it’s not new to me get new my ideas in places far away from where I’m “expected” to get them. I not able to conjure up ideas at my work desk all the time. It sometimes happen when I’m sitting alone, thinking about something else, in the shower or just at the coffee machine, no, errrr…. I mean, at the water fountain ;-) I think I’ll try to take some of the ideas she presented, and try to experiment with them in my work life, hopefully together with my colleagues. And also, the Pomodoro technique was brought forward again, a technique I learnt some time ago, but got away from using...

Mary Poppendiecks presentation Deliberate Practice in Software Development was excellent. It touched a subject very dear to me, namely the development of talent within an organization. Her speech was not about the, in my opinion, often misunderstood and misguided classical IT career path development we see so often, where developers are expected to become architects, who then should become project managers, business managers and so on. No, this was about developing experts through mentoring and finding the right challenges for the employee. The message was also, that developers right out from school not necessarily can be thought of as experts, and neither can experts developers in a domain that is new to them. We all need mentoring all the time, and so even the mentors also have mentors. Through long and wide experience will experts emerge… (again, this is just a few things of the points made)

As a person with 10+ years of experience in development, architecting, consulting and 4 years of running a business, this has much value to me. I have never believed in the classical career path that having to become a project manager is the only way for developer to advance in their career, however, that idea is unfortunately rooted very deeply in many companies. Let’s start a revolution and start mentoring! :-)

The last session of today was Philippe Krutchen’s The Representation of Architectural Knowledge, wherein he presented his ideas about the necessity of capturing decisions during development of a system. He went through the history of architectural representation, types of diagrams and methods, and the main idea was basically that they presented a model at a certain place in time, but that we could not get answers from the diagrams about why the architecture is as it is. By capturing decisions as well, we would, in the future, be able to get better answers to questions about the architecture than “I can’t remember, but I remember that is was because of something important...” (haven’t we all heard that one?) (again again, this is just a few things of the points made)

The question of why a thing was done as it was is not a question asked seldom by software developers. If you’re lucky, you can answer it yourself through the paradigms used or get the answer from the developer who made it, because he/she is still a part of your team (and can remember!). In such case the need for decision documentation would be low. But when the timespan between the making of the system (or a part of it) and when the question is asked is counted in months or years, well, then you could be in need of such documentation (so, in other words, you’ll basically always need it). Who haven’t tried sitting with code, thinking “why on earth did they do like this”? You have the notion that there’s some hidden significance, maybe from the patterns of the code, but the answer is not clear. In such case I’d love to have full structured documentation… (How about you, Henrik? ;-)

Pictures from the day:

More books… mmmMMMmmm…

Linda Rising…

Samples from Linda’s presentation…

Michael T. Nygard…

Mary Poppendieck on Dedication… all good things, but notice the last remark.

Philippe Krutchen – a very intelligent, animated and funny presenter.

Decisions visualized…

Now I’m heading home for Malmö, Sweden to my girlfriend, from who I need a big hug. :o)