I thought I was done with ranting about automation tools for a while, but I couldn’t resist this quote from my former boss’ blog:

“Tools that let programmers create software by manipulating icons and graphics shapes on screen have a long and sometimes successful history… But these have generally served as layers of shortcuts on top of the same old text0based code, and sooner or later, to fix any really hard problems, the programmer would end up elbow-deep in that code anyway.”

There’s more good software-development food for thought in his full post, so why not check it out here?

Michael has moved to a new city, and is obviously free of social distractions. That, or there’s something physically stopping him from playing World of Warcraft. Anyway, he’s blogging again and his latest entry (http://www.ruschena.org/michael/?p=107) on writing technical requirements is well worth a read.

Spare a thought for the people that recently hired my friend Steve, as you read about his latest job (in the second last paragraph):

http://cramdogg.blogspot.com/2007/02/watching-printer-101.html

After an email exchange with Matt Heusser, Matt has posted my comments on how our work tools sometimes influence our behaviour on projects. That’s because these work tools are based on models of how someone believe software should be developed. Perhaps more importantly, the tools that I’ve seen are usually designed to ensure that the team conforms to a process, not to ensure that the right things have been done.

The tool that I feel most strongly influenced the agile process in a former employer, is the workflow tool. Workflow tools are typically linear flow tools. I believe that the use of these kinds of tools (in our case, JIRA, but you can substitute most bug tracking tools if you like,) strongly reinforced a linear model of software development. I’m not aware of any tools that don’t model software development this way, but am quite happy to be shown to be incorrect.

If you don’t want your team throwing their work “over the wall”, check that your tools model development the way you think it should be done.

In the context-driven software testing Yahoo group, there has been an interesting thread on magic numbers. Part of this discussion related to magic numbers for software maintenance investment. While I think you can find plenty of literature that advises a bias towards maintenance, my friend Michael couldn’t find any models that satisfied our burning questions, so he built his own.

Check it out, and thank him for doing my homework

One more word on XP as methodology (well, a few more actually).

Any methodology seems to me to be a snapshot of a solution to a particular problem that somebody solved at some point, with a particular set of people and skills in a specific context. There are occasional statements flying around the agile-testing group which suggest to me that the intial applications of XP were either in similar contexts or recreated the important aspects of the original context.

One of the things that strikes me about the thoughtful practitioners Michael describes (and that I’ve been able to observe) is that they are actively seeking to solve a problem. They evaluate a development approach that they hope will solve the presenting problems they have, optimised for the skills that the team possesses and the organisational context. Then they attempt to solve their problems through the application of the designed approach.

My snapshot of some of the important attributes of XP’s context is this -

- Poor or non-existent testers and business analysts.
- Developers who were quite good at testing their own code and focusing on the business domain.
- Knowledge residing in customers’ (or analysts’) heads struggling to be free.

I’m convinced that there are many applying XP who have never really given thought to the problems it is designed to solve, the skills that are required to apply it successfully, the people required to make it work, how it might affect those who don’t fall within the XP developer circle and whether it is suited to their organisation and its culture.

We may then witness some of the following -

- Alienation of those who are not developers while the developers ‘do XP’ (by the book).
- Sub-optimal use of the skills of non-developers.
- Disappearance of team members who get less than two paragraphs of description in the XP book.
- Practices not solving the problems they were designed to when the underlying values or principles are not present.

It’s hard work to tweak XP to fit a team that isn’t just customers and developers.
So think about it. What skills do you have in your team? In whose hands do they lie? How will you work with the people around you to get the most out of your project, not just the developers?

I’ve shared some ‘perils of XP’ conversations with Michael of late, so I wanted to consider my experiences on the topic.

One thing that strikes me about software methodologies is that like many things which are written down, recorded and/or institutionalised, the reasons are often long forgotten. The early adopters are typically passionate, thoughtful, and (I believe) seeking to solve a very specific problem.

Those that come to the team later may learn the practices that the current team is using, but never understand the problem that those practices are intended to solve. Indeed, the existence of the practices may cause them to never witness the problem at all. This may then lead to the Routine behaviour that Michael describes.

I’m also thinking that while writing down our values and principles as a guide for others is helpful, it may be more helpful to explain the journey that led us to our current thinking. Of course, we are usually slow to learn from the experience of others. I’m not yet sure how we instil just enough fear and understanding into those who haven’t experienced the pains of yesterday, but it seems like an important thing to do.

Before applying any software development approach (or modifying an existing one), it might help us to ask a few questions -

- What problems are we trying to solve?
- How might all of the team members best work together to solve these problems?
- How will we know if we’re succeeding?

- that you’re going to get it right first time.
- that nobody knows better than you do.
- that it is going to be faster if you do it all at once (tightly coupled to the first point).

Another possibility might be that you’re afraid of negative feedback, which, in the context of working on a software team, is delaying the inevitable.

I’m sure there are more possibilities.

Problems with our assumptions

That you’re going to get it right first time

How might we behave if we assume that we are not going to get it right?

That nobody knows better than you do

How might we behave if we assume that everyone might know something we don’t?

That it is going to be faster if you do it all at once

How do we know that ‘faster for me’ is necessarily faster for the project overall?

Jon Eaves was blogging about problems related to development goals not aligning with business objectives and it resounded with some thoughts I had been having on company values.

In addition to goal alignment, I’m thinking at the moment that alignment of values is equally important, or at the very least it helps when the true values of the company are clearly stated. Goals tell us where we want to go. Values help us make decisions along the way.

While individual values may vary from the company’s, by being conscious of our own goals and that of our employer’s, we can discuss the differences, or at least see just how wide the gap is between one’s own values and one’s employer. I think this is a good starting point.

I overheard the following sentence from a project manager, accompanied by shock and outrage:

“Two *resources* didn’t turn up this morning!”

I believe the word they were looking for is “people”.