Book review: The Blind Men and the Elephant

This excellent book by David Schmaltz challenges the reader to examine the fundamental views they have of themselves and their work. It asks: What do you want? What is your purpose? Can you find 'your project' within each project you undertake? If you cannot enagage and participate meaningfully on a project, then can you - should you - participate at all?
Some sample quotes:
- "A healthy human system... reveres variety over similarity, choice over command"
- "We need more than horseflesh on our projects today - we need the active questioning judgement of every [individual]"
- "There are always 101 good reasons why I can't plan my project yet... No one wins this contest by generating 102 good reasons to plan. They win by generating one small reasonably good reason to plan anyway and then just getting started"
- "Don't allow yourself to be a Village Idiot, dependent on others to tell you the meaning of your own experience"
'Blind Men' is short, well written, inspirational and thought-provoking, and I can't recommend it highly enough. It lays bare the lack of humanity in a typical project environment, and considers what would happen if the Master-Slave relationships that bind us were stripped away to allow true group coherence to emerge. Read it!

Can't get no satisfaction

Hard to believe or not, software developers are people. They feel a mixture of dread and anticipation as they consider the day's work ahead of them, just like anyone else. And the way that they feel directly impacts their productivity, just like anyone else. As Martin Fowler wrote:
I can hear many people wondering who cares about whether developers enjoy their jobs. Actually I think it's very important. A team that's enjoying their work is a team that's motivated to do good work. In raw business terms, this translates to much higher productivity and better value for your development budget. I've always argued that development managers should devote a good proportion of their energy figuring out how to motivate and energize a development team.
The problem is that it is much easier to demotivate a team than to motivate it. (And when a team reaches rock bottom, almost any motivational effort - no matter how well intentioned - will be misinterpreted as it filters through the layers of negativity and cynicsm.) So what is a manager to do? Simple: try to treat your teams like people, as you yourself would like to be treated.
Make the effort to get to know your developers, acknowledge their individuality, and recognise their desire for self-expression. Offer assistance when they are stuck or direct them to help when they appear to need it (heeding the messenger however the message is expressed). Ask them for their suggestions, and provide feedback if the ideas are politically or economically infeasible. As Hal Macomber also wrote at about the same time as Martin's post:
It's time we stopped acting like good technical wisdom is what makes for good project management. It doesn't. Likewise, accountability, authority, and responsibility [...] don't make a project manager. Let's try care, guidance, attention, listening, and openness.

To coach and to coax

A coach usually has no explicit authority, so they often have to coax team members into taking action or reconsidering an opinion. Sometimes this is easier when taking a particular stance, and asking a leading question:
Reflecting: "So if I understand correctly then what you're saying is..."
Prompting: "Have you considered [doing] / [thinking about]..."
Positing: "What if [this were true] / [that were to happen]..."
Suggesting: "If it were up to me then I would..."
Connecting: "Have you talked to [her]? She..."
Digging: "Is that really the problem?" / "How do you know?"
Challenging: "So what are you going to do about..." / "Is doing nothing an appropriate response to..."
Aiming: "What are you really trying to achieve?" / "How will you know when you're done?"
Steering: "How would you get there from here?" / "Can you break that down into smaller steps?"
Focussing: "If you could only do one thing..." / "What's the first action you can take?" / "What is most important right now?"
Summarising: "So, the problem is... the alternatives are..."
Chairing: "Shall we take a vote?" / "Give [him] a chance to speak..."
Smoothing: "Why don't we take a quick break..."
Marshalling: "I hear what you're saying but we'll have to come back to that later: right now we need to... "
Taking an interest: "What's new with... That sounds interesting... How does it work?... How did you come up with..."
Encouraging: "Well done..." / "Thank you..." / "...which is a big step forward" / "...which really helps"
Obviously these stances only pay off if the coach actually listens to the response that they get.

Postscript: If this list of stances seems helpful to you then you ought to check out Esther Derby's post on the method of Focussed Conversation

Use of the word "Test" considered harmful

Brian Marick's recent blog posts point out that the word "test" is too loose to be useful to TDD programmers. He suggests change detectors for backward-looking "programmer tests" - those that alert us when we have significantly changed the structure of the software - and code-guiding examples for forward-looking "programmer tests"- those that provide a specification of sorts for the code that we are about to write. And perhaps controversially he questions whether a single technology - be it JUnit or NUnit or whatever - can meet the needs of both detecting changes and guiding progress. Interesting.

XP rollercoaster hits the Wired bandwagon?

It's nice to see Wired magazine giving XP some positive press. I just wonder whether this sort of breathless exposure will hasten the change from "wired" to "tired". XP is not a silver bullet: it does not work for everyone or on every project. (As Geoff also points out in his blog entry about this article). In particular, one of XP's weak spots is that it's hard to do it right (and that's why you need a coach to help you keep on track!) Over time the number of failures stemming from the well-meaning misapplication of XP will increase. It seems inevitable that XP will eventually be written off as just another fad. So where does that leave those who find that it really works for them?

People need scheduled maintenance too

It's called a holiday (and yes I've just had one).

Good design == the absence of design smells

One of the points that Bob Martin makes in his excellent book "Agile Software Development: Principles, Patterns, and Practices" is that the concepts of good design are hard to pin down, but examples of bad designs are plentiful. He lists several design smells that can / should be mitigated through refactoring, e.g. (if memory serves me right):

• Rigidity: it is difficult to add new features
• Fragility: small changes break the software
• Immobility: the software is hard to reuse
• Viscosity: it is easier to do the wrong thing than the right thing when making changes
• Needless Complexity: the software is over-engineered or makes too many allowances for possible future scenarios
• Repetition: the software violates the DRY principle (often when the team is infected with copy-and-paste-itis)
• Opacity: the software is difficult to understand

Obviously these smells are interlinked, and opacity in particular is the root of many evils. But what is surprising is how often teams become immune to the presence of pungent odours in the code base: even when it is slowing them down and making them frustrated. So next time you open your IDE somewhere at random in your code just stop for a moment and breathe in: what are you smelling? And more importantly, what are you going to do about it? Smells just don't go away by themselves you know...

Not tonight, Josephine

These are all worth a longer post but for lack of time these links will have to do:

• O'Reilly has published an XP Pocket Guide
• Admitting you don't know is hard to do: "the company pays managers to make good decisions, not be omnipotent". (Was it Socrateswho said that "wise is he who knows what he does not know"?)
• The Top 10 Sources of Project Failure seem eerily familiar...

How we think about code (updated)

Darren was showing off his FingerWorks Touch-Stream keyboard today, and it sparked a discussion about how we think about code. Basically his keyboard is a giant touchpad that combines the work of a keyboard and mouse, plus it detects complex finger movements and interprets them (e.g. as cursor movements, as cut / copy / paste, or as file-open / file-save).
This ability to perform gestures as well as type is what the discussion revolved around. Some people said that they couldn't see what the fuss was about: to them code was just a stream of characters in a file, and no expensive gadget would change that. But others immediately started raving about how gesturing at their code (or even 'in the code') allowed them to start interacting with it in a way that felt natural. It was is if their internal 3D model of the codebase was brought to life, e.g. performing an extract method refactoring by reaching into one method and physically pulling part of it out. The discussion moved on to talk about programming with data gloves and other sorts of input devices, but to me the most interesting thing was hearing developers talk about visualising code, as if they can translate O-O language concepts directly into imaginary solid things.

Diversity and monoculture in software development

Esther Derby makes a good point about monoculture and recruitment: hire people who are too alike and the organisational meme pool shrinks. As it shrinks, recessive memes start to dominate individual and group behaviour, and before long a monoculture is established.
But while I agree with what she says, I think that monoculture is endemic in software development for reasons beyond just recruitment. Monoculture emerges very quickly in software development teams that impose a 'standard' IDE and OS, that use a predictive (not adaptive) lifecycle process, or where developers are expected to work the same hours on rigid pay scales in cube farms while adhering to a dress code. The recessive memes in these organisations are expressed in beliefs such as "all projects are the same", "developers are irresponsible" and "we know what the users want without needing to talk to them".
The first sign of a monoculture is often the absence of dissent giving the superficial appearance of order and control. Whereas an organisation with a healthy level of diversity can appear to be on the edge of chaos. This is certainly the case in companies with an agile software development culture: one that is goal (not task) oriented, encourages interaction and feedback, allows self-organisation, leverages groups (not just individuals), and values experimentation. These are the conditions where diversity thrives.

"You aren't being paid to believe in the power of your dreams"

Alan Francis' post about demotivation got me thinking. I suppose that some people want a simple 9-to-5 job, or are happy to be told what to do and when to do it, but most software developers I've met want more control over their work than that. They mostly dictate how they write code and they want an influence over other aspects of their project environment as well. Especially if they believe that something about their project isn't working, or isn't logical. Developers fix problems with code all day, and to them a project issue is just another sort of problem that can be fixed. And by fixed they mean tweaked, or changed. (The most subversive developers of course just change things themselves, though they usually can only get away with it if they have the tacit support of their management.)
This is why talented and energetic developers find it so crushing to be told, "Just get on with your job". It makes it clear that their relationship with the project and employer is unequal, and that any change they desire will be resisted. Which is a shame, because denying all potential change will just stop the project from maturing and improving. As well as squandering the developers' goodwill and constructive energy.

XmlUnit for .Net

Shameless self-promotion time: the first version of XmlUnit for .Net is now available at SourceForge.net The code is still in the early stages (though it works and has tests!!!) but it is already interesting how using the Microsoft 'pull' XML parser has produced different code from the DOM-based Java version.

Learning from the military

Armies and navies have been motivating, leading and organising people for centuries now, so perhaps there are some things that we can learn from their experiences:
Volunteers do it better
- Conscription is the last resort in most successful military endeavours. But how many team members sign up to software projects, rather than being drafted on board, often unwillingly?
Match the mission to the people
- Military commanders know that it's easier to change a mission than to change people. But how many software projects are commissioned with a specific team - or type of team - in mind?
Training matters
- You might only get one chance to do it right, so learn to do it right and practice until you just don't get it wrong. But I wonder how many companies are investing in comprehensive training plans for their software developers at the moment?
Limit time spent at the front line
- A tour of duty defines a concrete duration to front line duties, and allows troops an opportunity for the 'R and R' that they need. But how many difficult projects drift on and on, with no end in sight for the developers apart from projected dates that keep slipping?

A little humour goes a long way

My six year old daughter told me some jokes this morning as I got ready for work. Here are couple that made me smile:
What goes ha ha plop?
- A man laughing his head off
What do you call underwear thieves?
- Nickers
What do you call the boss of a tissue factory?
- The hankie chief
I don't know about you but I think a bit of silliness starts the day pretty well...

If software coaches were more like sports coaches...

The analogy between software coaches and sports coaches is sometimes overstretched. But what if software coaches were more like sports coaches?
Well, prescribing a healthy diet and modest exercise regime would probably help boost the brainpower of most software teams. As would ensuring a reasonable amount of sleep: so no more all nighters, less caffeinated drinks, and get out of the bar before it closes please.
Sports coaches also organise and oversee group practice sessions (refactoring today, FIT tests tomorrow perhaps?) to improve the team's performance - as well as catching injuries or dips in form as early as possible. They determine who makes the grade from the squad on to the team, only selecting the best and most motivated players to improve the chance of a good result. Perhaps these techniques could be made to work for software teams too.
But I think that the best thing software coaches could learn from sports coaches is that they need to know what makes their players individual: their personality, their circumstances, what spurs them on and what holds them back. As deMarco and others have been saying for years now, maybe treating team members as people is the key to getting the best performance.