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…

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.

Build information radiators are useful for improving the visibility of the state of the build – bright green if it’s good, or bright red if it’s broken. On our current project we’ve been trying to assemble all the hardware to get some lava lamps going, but in the meantime we’re using a very old PC and its tiny CRT monitor to glow bright green or red.

A problem we had was the Power Options settings turns off the monitor after 20 minutes of (in)activity and it’s been too difficult to get Administrator privileges for the machine. Although not necessarily the most ideal solution, the most amenable one for Friday was a small program that moves the mouse cursor every the minutes. Get the results here if you want.

Usage:

java -cp MouseMover.jar <number of minutes each time you want the mouse moved>

One of the benefits you get with consulting is that you get to see a variety of applications, processes, and in agile projects, different build pipelines. I take the developer loop very seriously, because how quickly you can get feedback determines how quickly you get serious things done. Different testing strategies are an important way of improving the amounts of feedback (as long as you can still write meaningful tests). Another technique is the ease with which you can configure various libraries, integration points and environments. Even splitting the build into various stages where failing earlier is more appropriate can help you get better feedback.

The ultimate feedback loop I’ve seen in Java is the “change-compile-run test” loop. Anything more and you will decrease your feedback cycle and adversely affect how fast you can develop. Anything less than this is unacceptable – skipping the “run test” stage doesn’t do anything to validate that what you wrote actually works. On a side note, in an interpreted language, the loop is even tighter, simply being “change-run test”.

J2EE’s “Enterprise” Feedback Loop
I’ve worked on numerous J2EE systems that were all business successes. As a developer though, it still makes me cringe thinking about the feedback loop, and how long it takes to make a change to a class, or one of many, many XML files, jar up something several times, and then actually test it.

Optimising Your Build Loop
Visualising your build process is an excellent way of seeing exactly how many hurdles you have to go through to get any decent feedback. Even better is trying to work out which things you *really* need in a build and removing anything that just doesn’t add any value. I try to aim for the simplest and fastest feedback that you can get using the above diagrams as the ultimate goal. Give it a go!

I started at a new client yesterday, and we had a great conversation on my thoughts about working overtime. Anyone who has worked with me in the past knows that as a principle, I heavily dislike working overtime. I think I provided some pretty good reasons and thought I’d write about it.

I am a big believer in the “Sustainable Pace” concept because I think that quality software development is a limited resource. Even though I dislike working long hours, they’re inevitable because of various reasons, and when I’ve worked long hours, and witnessed other working long hours, I’ve observed developers get tired, and when they get tired, they get sloppy. For a project that will be running for a long time, you really don’t want that.

The reason I think of it as a limited resource is because if you have ever done solid software development, you will find it requires constant judgement, thinking and in general just solving problems and puzzles all day. It requires a large number of micro decisions and is a tiring exercise with a physical limit for how well you can sustain this before quality starts to suffer. Imagine playing sudoku all day long and see how long it is before your brain starts to tire (and I just did that with the amount of flying I recently went through!)

Of course some people handle this differently. Some developers I know, prefer to spread out this thinking with various breaks of checking email, surfing the web, etc. I’ve heard of stories where some developers will do these bursts in a series of several consecutive long days, but have lots of down time in between. These developers should never be confused with developers who are just lazy and continually check email, surf the web, or better yet “work from home”. I also think that the latter developers have no pride in their work and should not be in our industry.

I do agree that in some circumstances, it is important to be able to tap into “extra hours” and that it should be exceptional circumstances. The illusion that needs dispelling is that there are no “extra hours”, and that at some point, developers will need to rest and to be effective.

I suggest to business people who I’ve worked with that it is better to maximise the value you can get out of the limited resource, instead of trying to mine more of the resource. Oh, and did I mention that maximising business value is what agile is about?

Even though I was accepted for Agile India last year, I wasn’t able to make it because of extraneous circumstances. I found out last weekend that I have just been accepted to present a TDD Swing Workshop at XP 2006 to be held in Finland. Woo hoo!

1. Initial – You don’t test or manually test in an ad hoc manner
2. Repeatable – You start building test suite(s) that can be run repeatably
3. Defined – You automate your test suites and run them in a continuous integration environment
4. Managed – You start observing metrics from the tests such as how good the coverage is, how long it takes to run and how difficult they may be to write
5. Optimising – You start to make changes to your code to make it easier to test, and you use the tests to highlight areas that need refactoring or a redesign. You start running Test Driven Development or Behaviour Driven Development to enhance the testability of your code.

After applying the CMM to way I execute testing, I find it interesting that the practices that emerged from the agile community are heavily biased towards the higher end of the CMM. There’s definitely a message here.

Disclaimer: This list was created by myself and does not reflect any official source associated with the Software Engineering Institute (SEI). It was written by me in terms of thinking of how I have seen testing executed and then trying to describe it in terms of the CMM.