Agile Development Conference

I didn't make it to ADC this year (I wanted to do so but I couldn't get the time and money together... though I will be attending the AYE conference in November which I am really excited about.) Anyway I know several people who did make it there and it sounds as though there was a real diversity of topics discussed and experiences shared. (Andy Pols has blogged his view of the highlights, and he should know...) I believe that conferences like this demonstrate that "agile" has become more than just a marketing term, despite differences of opinion about what the precise definition of the term is.

Red-Green-Refactor = Add-Add-Remove

Are there just three steps to TDD enlightenment?

Step 1. Add code:
Write a test. Run it. Watch the bar go red.

Step 2. Add more code:
Write just the method or class implementation needed to make the new test pass. Concentrate on making the smallest number of changes and resist the urge to keep the code clean. Run the tests. Watch the bar go green.

Step 3. Remove code:
Improve the code by refactoring. This will almost certainly involve removing code, either by deleting duplication or simplifying complexity. Re-run the tests. Watch the bar go green. Repeat this step as needed or return to step 1.

Reflection: when you refactor do you find yourself removing code? do you like or dislike removing code? does the answer depend on whether "your" code is being removed by others or by yourself? should it?

Urgency, importance and technical debt

A useful piece of time management advice is to distinguish between tasks that are urgent and tasks that are important - and then to ensure that important-but-not-urgent tasks (which are often overlooked) actually get done. Which seems a lot like the advice for software development teams to avoid technical debt. Repaying or avoiding technical debt is important but is rarely foremost in the minds of customers or managers. And despite the adage that "you'll pay for it [technical debt] today or you'll pay more for it tomorrow" software development organisations are often unwilling to confront the scale - or implications - of the problem.
Reflection: Do you find yourself fighting fires more often than you are creating fire engines? Is refactoring treated as an optional extra task in your estimates? How might you maintain a better level of slack? What can you do if you recognise the symptoms of undertime in yourself or those you work with? What time management lessons would your team learn if time were available for retrospectives between project releases?

Postscript: I recently caught up with Dave Hoover's blog and this entry struck a chord. To bring this back into the realm of software development, the problematic symptom is time pressure. The fundamental solutions that could treat this symptom include delaying the release or shipping without the functionality... One of the easiest and most immediate ways to suppress the symptom of time pressure is to stop writing unit tests.

Organisational patterns finally made it into a book

I heard Jim Coplien speak about organisational patterns at a BCS OOPS conference back in 1997, and it seems as if he is now publishing his ideas in the book Organizational Patterns of Agile Software Development. (BTW because of the book's long gestation period some of the earlier material is still available on the web. Take a look at the "Architect-Also-Implements" pattern if you do nothing else.) It looks as though the book will be a must-read when it comes out.