Work-Related – Page 5 – thekua.com@rest

XP2006 Day 2 Short Summary

June 20, 2006 Patrick Agile, Work Related

I’ve been having troubles posting things to my blog due to Internet access here, but this entry was written just after Sweden and England drew in the world cup (equivalent of midnight here in Finland), so here’s the recap of today’s goings on:

Barry Boehm’s keynote – An interesting discussion in which he discussed different analysis models that could still be used in agile, considering risk management and balancing agility and discipline. He talked about the scaling of agile to scrum of scrums and research indicating where agile is most applicable.
Panel of Notable Agile Leaders including (Angela Martin, Rachel Davies, Jutta Eckstein, David Hussman, Emmanuel Gaillot, Mary Poppendieck and Michael Feathers) holding a fantastic discussion on Politics and Religion in Agile Development. A lot of the advice they gave and their own ‘war stories’ struck a chord with me so much in my experiences and different projects I’ve worked on. It was great for them to all be so honest and give their opinions. Kudos to Angela for being an excellent moderator for the session!
Value Stream Mapping – An excellent exercise with Mary Poppendieck, involving identifying waste in an entire value chain (i.e. when a customer requests a features and they are using it), and more interestingly the strategies or areas of focus for particular project examples.
Coder’s Dojo – Coming half way through this session, I still had lots of fun with this hands of workshop presented by Christophe Thibaut and Emmanuel Gaillot. We did a bit of dynamic language group pairing adhering to a small set of well defined rules that I found fascinating from many different perspectives, most especially the social one.
Final keynote by Jack Jarvik discussing methods he applied in the early 1990s that appear aligned or similar to many of the XP/Scrum practices.

What can I say, but what another fantastic day?

XP2006 Day 1 Short Summary

June 19, 2006 Patrick Agile, Work Related

I’m keeping this brief since I don’t have time to write more and want to keep a track of significant things came up today.

Pekka Himanen presented the keynote, The Hacker Ethic discussing environmental issues and attitudes that make up, not what I interpret as just a hacker, but someone who is passionate about their work and the things that can help sustain or maintain their energy levels. Things like building up a sense of community and trust certainly help.
I was a little disappointed with Agile Development with Domain Specific Languages, in that it was fairly tool centric – with MS DSL tools for Visual Studio and Metacase. We had some post discussion had about whether or not a meta model was actually needed for a domain specific language (i.e. do you need to validate the language the user is using, or just trust that they are doing the right thing).
Open space sessions – I think trialled for the first time in the European series of XP conferences, were extremely popular with well over fifteen dynamic sessions planned. I actually just got back from attending one scheduled for 10pm back in the hotel, throwing about DSLs vs FIT and which one was better.
My presentation on building Agile GUIs went quite well – got some great feedback and helped some other developers writing client side applications to validate or assert the things they were doing.

I got some great feedback in that, yes, the acceptance tests I used as an example could be written in a script-friendly manner (with a few new tools such as JUseCase and Exactor), but there was nothing that would stop me from refactoring to FIT or any of these other frameworks. The focus of my presentation was not focused on how you write acceptance tests (since people like FIT have already addressed this), but rather how you go about building up the different components, and Acceptance Tests spawning additional unit and unit integration tests to get the Acceptance Test passing. It looks completely different from any normal Swing code you would ever see tutorials for.

Great meeting with lots of people in the industry and lots of people you have read, but were great meeting. The workshop with Mary and Tom Poppendieck on the weekend was great, but now I’ve also met heaps of other interesting people such as Charlie Poole, JB Rainsberger, Mike Hill, Mike Feathers, Erik Lundh, David Hussman, and Jutta Eckstein just to name a few.
The final keynote of the day was interesting about how, five or six years down the track, how successful has the agile movement been and where do we go from here. It was presented by Sean Hanly, who works for the main sponsor of this year’s conference and I think he put it together fairly well. Paraphrasing him, how do we keep the heart and principles behind agile as it continues to be used and ‘abused’ so that it doesn’t end up on the same process graveyard many other processes have been.

Whoops, I said I’d keep it short, but oh well…

Embrace Change, But Never Force Change

June 13, 2006 Patrick Agile, Work Related

Being on new projects brings lots of new opportunities for learning, especially when dealing with lots of new people. I consider myself one of the more experienced agilists on our current project and I realise that the way I am used to working on projects will be fundamentally different from one that hasn’t had my experience. I like things to be fast, dynamic, self-empowered and interesting but this isn’t always the case for everyone.

As I further refine my skills as an agile coach I like to approach projects with an observe-advise-implement mantra all based on developing trust and getting the most effective results for the project, team and business. It’s all a very tricky balance to maintain as often these goals are not aligned with each other.

One of the benefits of being fresh on a project is that you can bring a different perspective and suggest improvements to parts that others may have already developed a thick skin towards. One of the things that, as a new person, have to change is the way in which you worked on previous projects.

I heavily disagree with evangelists that need to apply the same practices on their current project simply because it worked on their previous project. As a change agent to a project, you want to avoid changing things simply because it’s not the way that you’re used to working. Applying the same practices from previous projects may never work because you are dealing with different people with different skills and strengths.

A better approach is to highlight any weaknesses or inefficiencies you might see incrementally and suggest alternative practices that might work better since there might be a plethora of them to choose from. You want to get as much of the team involved as possible with making a decision since people resent having change forcibly thrust upon them.

As a process coach, you need to respect that everyone has different abilities to cope with change and like with most good things, introduce them incrementally.

Tell Me What You’re Testing

June 12, 2006 Patrick Work Related

It still seems that no matter how mainstream particular technologies get, many developers do not clearly understand how those technologies should be applied. One developer I’ve worked with in the past before always stated that they wrote ‘JUnits’, which is admittedly, better than people not writing tests, but they still didn’t make it clear what sort of testing they were doing. I’ve also seen this same mistake applied in a build for a suite of tests marked as ‘FIT’ (a different framework for testing).

The thing that bothers me about statements like this is that JUnit and FIT libraries are a means to an end. JUnit is great because it is so mainstream and simple that people can quickly understand how it works. Stating that someone is about to write a JUnit is like saying to me that they are about to go and write java (well duh!).

One of the most useful things I find on a project is building up a common understanding of the groups of tests. I have my own starting point, and adapt labels depending on how strongly people feel about their own understanding levels. I like to begin with at least three levels of tests including:

Unit tests
Unit integration tests
Acceptance tests

The first level of tests are sometimes better referred to as class level tests, and are intended for testing code at their most granular level (such as a method, etc). They should be able to run without any external dependencies.

Unit integration tests – something that I may refer to as functional tests should be applied when classes have a higher level of interaction – sometimes with each other, or more importantly something that will slow down the tests suite – such as a file system, a networked system or a DB (yes, even an in memory DB). These tests typically are IO bound, and may even require external configuration or setup before execution.

Acceptance tests are intended to test the configuration and the ‘wiring’ up of your application. Tests will be the longest running part of your suite since they are testing parts of the code over and over again through various paths, but these ones validate that the application is meeting the business value that drives it. These tests should simulate real life scenarios and interactions, but a failure in this suite should typically have a matching failure in the unit test build.

The choice of technology should always be secondary to the effort of communicating your intent, and should be reflected by the words that you choose. Saying what sort of test you writing is always much better than how it is going to be done.

The World Should Be Filled With Magic

June 9, 2006 Patrick Work Related

And that’s not just some long-haired hippie’s opinion. Wednesday night we had a mini-geek night at work and we got onto the topic of whether or not (code) magic was good or bad. It was a great conversation and because Ade doesn’t have a blog (when are you going to get one?), I thought I’d write about it.

I struggled at first to work out what we meant by ‘magic’ and we somehow concluded at some point, for it to be ‘the unknown’. For instance, when you plug stuff into the Rails framework, there’s some sort of ‘magic’ going on to hook it all up. The focus of the discussion was really about whether or not we thought magic was good or not.

To actually substitute our other meaning, ‘the unknown’ for magic makes the question a very strange one – ‘Is the unknown good or bad?’

My attempt at answering this question was that the concept of magic is not good or bad, but whether or not the attempt at magic is good or bad. In general, I personally like magic because it makes my life easier. I shouldn’t have to understand how the compiler, for instance, turns code I write into bytecode every time I want to do something. I like the fact that it just works and that’s how it is. The abstraction or illusion holds true every time I run it and I can depend on it to work day in and out.

I consider magic good if it doesn’t require you to understand it. Bad magic on the other hand is bad because it forces you to work out how it works, and that need, let alone the experience, is generally traumatising. It’s like a magician’s illusion failing us because you have to go behind the scenes to understand all the little tricks that made it work. What can make it worse is if it is difficult to investigate how it works such as the source code not being available, or horrible code that’s hard to read, or an abstraction that just doesn’t work.

All of this is circumstantial and really depends on how well the magic was built. If the magic works all the time (and generally that’s because the abstraction is sound) and it does all the things that you need, then I think it’s a good thing.