Weasel words

In the Development Team of the Future (DTOTF, copyright pending), all communication will be clear, open, forthright and well articulated. Sadly, our current development teams still consist of human beings, using writing and the spoken word, so there's not much hope of transitioning to DTOTF any time soon.

Ok, funny intro (at least I hope so), but what's the point? As I've said before, I think that most commercial software development is a social problem, not a technical problem, in the sense that we know we can build something but we need to figure out how to build it as effectively as possible with the team that we have. It's about people, and people are often poor communicators.

One of the things I encounter fairly often is people using what I think of as "weasel words". They're words that hide conflict under the cloak of respectability. When you're hit with a weasel word you need to choose between abdicating your position (often with some new emotional baggage) or moving to open contradiction and conflict. If you're inadvertently flinging weasel words around you may be surprised by the results!

So what are the weasel words? There are lots, but my list starts with these: "just", "must", "have to", "pragmatically", "realistically", "in the real world", "in practice". "Just" diminishes, trivialising the problem; "must" and "have to" beg the question "or what?"; "pragmatically" and "realistically" imply that the other person isn't being either; "in the real world" and "in practice" label the other position as somehow irrelevant. They all have uses in the right context, but they're also frequently disrespectful.

If you find yourself about to use one of these words (and these are just examples, not an exhaustive list) ask yourself if they're necessary, if they're adding value to your expression. Or try living without them for a while and see how things go. My personal quest for the last 18 months has been to eliminate "just" from my vocabulary, or at least minimise my usage. After all, it's just one word - how hard can that be?

Whose problem?

This post takes me back to my earlier theme of developers as change agents, which had a holiday while I was thinking about the EAT workshop. In my earlier posts, I talked about different people perceiving a problem differently, but there's a particular aspect of this that deserves more attention - even if we all see a problem, who's problem is it? To mangle a Mel Brooks quote, "My problem is a tragedy, but yours is a comedy".

The best way I can describe this is to talk about a real life situation. It's not a once off situation, so I don't have to reveal any secrets or worry about offending individuals. This sort of thing happens all the time. It happens when management is unhappy about development for some reason, but are a little vague about the exact problem. "We have to do better!" echoes around the table in closed door meetings around the board table. Perhaps it's the sales folk speaking loudest, "We're not meeting customer expectations" they say. This message gets passed down the hierarchy; "Make it better" is the refrain.

There are a few layers involved, but eventually the message trickles down to the developers on the front line. Their team leader gets the message clearly (sort of), "Job number one is to make the development process better", and heads off to do so. She has a meeting with the team to tell them that she wants them to do better, but they're quite happy with the way they develop software at the moment, thank you very much. They feel they have a pretty good idea of what needs to be done, defect rates are manageable, hours are pretty good, they get to solve some cool technical problems, and they've each got some nifty noise cancelling headphones. The message falls on deaf ears. As time goes by, each of the team leader's initiatives fall by the wayside, and management sees no change at all.

What's happened? Two things that I can see - the people who needed to live the change didn't actually have a problem. They were quite content, thank you very much. The message "management has a problem, you need to suffer some discomfort" doesn't really resonate very well. Although most of use help our neighbours to some extent, our selfish genes respond most fiercely when they're directly threatened, not just indirectly. So one of management's responsibilities (and I use 'management' in a very broad sense) is to make sure that people are motivated to solve personal problems. The simplest way is to translate problems into actual threats - "do this or you're fired", but it only works in the short term and not very well even then. Regardless, as a colleague many years ago said in reference to our startup CEO "I'm not working my ass off to make him rich". He would have worked his ass off to make himself rich though!

The second thing is that even after we all agree a problems exists and we all need to act, we still need to agree on how we'll measure progress. We need a metric, even if it's a very approximate one. Once we have a metric we can be involved in selecting as well as implementing change strategies, because we can try them out and see what worked, possibly in near-real time. Without that, we're reduced to following change implementation orders - not only is this less than fun, it doesn't give everyone the chance to suggest changes, and as well all know, all of us is smarter than any one of us! It's also helpful to have other metrics in place so we have a chance to measure unintended consequences of our changes.

So if you want some other folks to change their behaviour, make it personal and make it measurable. Encourage them to feel your pain, and help you to assuage it, rather than sitting pack entertained by the comedy of your suffering.

First EAT workshop

We ran the first EAT workshop on Saturday, and it went very well. The setup at the venue wasn't perfect, but we think we have a way to set it up better next time. I like an environment with plenty of light, but if anything we had too much yesterday (at least for projection) so we'll try setting up in the ante room, which has blackout curtains, next time.
And the feedback from the participants was very good. Thanks very much to Marty for co-teaching and for providing the data projector, and to Nigel for coming along and adding his expertise. I'm getting used to working on my MacBook, so I'll gradually get better as well. Alec Clews, one of our attendees, has posted his comments.

 

 

Although the examples and discussion for this workshop were in Java, we're now able to offer the workshop in .NET as well. We're unlikely to run the TDD workshop again for a while, but we'll probably run a design improvement workshop in March - contact us if you'd be interested in that.

Testing images

This is a photo I took while travelling in the US.

I hope it posts ok, but no luck so far.

Best Practices - Global or Local?

I came across "Debating the merits of pair programming" this week, and found it irritating. Lest anyone think I'm picking on a particular piece or author, it's just the latest irritant in a series. You could conclude that I was a just a grumpy old man, or that it was very early in the morning and I hadn't gotten my 'day face' on (and there'd be an element of truth to both these thoughts), but let me try to explain myself.

The article presents quotes both supporting and opposing the practice of pair programming, based on personal experience, and some academic work along with critiques o that work. Implicit is that we should be able to somehow look at both sides of the argument and decide which is right and which is wrong. This is the process that someone might be going through if they were trying to decide if pair programming (and by the way, I think it should be called 'pair development', but that's another story) was an industry best practice (you should be able to hear the fanfare in the background).

I have a problem with the idea of industry best practice, and as a corollary with arguments about whether something is industry best practice or not. Fundamentally, it's a problem of context. When we hear about a best practice, what we're usually hearing is someone saying "that worked in my context", where the context may include the developers, the technology, the customers and a plethora of other things. And I love to hear about what worked (or didn't work) in your context - it's the first step to deciding if that might work for me too. The second step is to understand the similiarities and differences between our contexts.

There's another problem with the presentation of the arguments about best practices, especially when there's a bun fight between the relativists and the absolutists. Absolutists are the people looking for industry best practice - one practice to rule them all, one practice to bind them. Relativists are the folks saying "this works sometimes - it worked for me", or "sometimes this doesn't work". When I talk about pairing, or agile development in general, I try to be a relativist. I can say that it has worked for me. I can try to describe the context in which it worked, how it might work in different contexts, and how it might fail in some contexts. Then I come up against an absolutist saying "Pairing doesn't work", "agile development doesn't work". Come on dude, I just told you that I have a proof by existence - it worked for me! Most times I walk away feeling like I've just been called, indirectly and implicitly, a liar. And sometimes I get a bit heated when I feel like that :-)

So here's my proposal. How about we stop looking for industry best practices, and put some more energy into looking at practices which some of us have seen work and figuring out what contexts encourage or discourage these practices. I'm game, how about you?

PS. Apologies for turning off comments in recent posts - I'm using a new tool and I missed setting an option properly.

Test Driven Development workshop notes

I've just finished porting my TDD workshop notes to S5, adding all the code examples, and in general buffing them up for the EAT workshop on Saturday. As usual, I feel that the value of the workshop comes from the dialogue and the interaction, not just from the slides, so I'm happy to make those publicly available, provided you leave the accreditation in place. I'm very interested in any feedback you might have - for example, I've just realised I need to add some Creative Commons licensing to the material, but I'm sure you'll have other things to say!

Do you really have a problem?

In the last post I talked about change capital, a way to think about how many changes you can confidently make and which changes they should be. However, once you've decided where to make your change investments you need to think about how to implement the change.

Most changes are triggered by a perceived problem. However you need to keep in mind that not everyone thinks there is a problem worth solving - they may be quite happy with the current situation, see a different problem, or agree that there is a problem but not think it's worth solving. So your first step is to articulate the problem that you are trying to solve, and then form a consensus around the problem description.

If you're anything like me articulating the problem, even just to yourself, is a very useful exercise. It takes an intuitive understanding and transforms it into something a little more rigorous. It forces you to consider your terminology, establish some consistency, and gives you a chance to check your reasoning. Including quantification of the problem, answering how much this is costing you, can also be very enlightening - sometimes problems are very annoying, but don't actually cost you very much. If that's the case you might want to put more effort into quantifying the annoyance - does that have an economic cost as well? I frequently find that articulating and quantifying the problem forces me to acknowledge that there isn't a significant problem - at least no one worth investing my precious change capital on.

Even after you've convinced yourself that you've got a problem, you need to remember that not everyone else sees the same problem. Some people will probably agree with you, some people will see the same problem but won't think it's worth fixing (especially compared to other problems), and some people won't see any problem at all. And maybe they're right! Maybe there are benefits to the current situation that you haven't seen. Perhaps the benefits accrue to other people, so it's worth bearing the apparent pain. Maybe there's something else that makes the situation fine in a larger context. Software developers frequently believe that their employer should be focussed on optimising software development, but that's often not the most important thing at a corporate level. Maybe it's more important to leverage other staff, even it's detrimental to software development. Try to see things from other people's perspective. You'll know you're doing a reasonable job of this when you can paraphrase their position, echo it back to them, and see them nodding their heads.

It's really only when you get to this point - where you understand the other person's position well enough to describe it accurately to them, and you still believe that there's a problem, that you can start to move towards a solution.

EAT update

With just over a week to run, we've got 10 bids for the Test Driven Development workshop, which is great - this means that bidding will close on midnight Friday. If there's sufficient demand in the next few days I'll look at running this workshop again in February.

EAT details

BarCamp Melbourne

I've read about BarCamp, especially in the blogs of Kathy Sierra and Tara Hunt, so it's good to see that there will be a BarCamp Melbourne in a few months. I hope to be able to attend but I'm not sure about that at the moment, which is why I'm not on the attendee list.

Marty Andrews co-teaching TDD course

I'm pleased to announce that Marty Andrews/ will be teaching the EAT TDD course with me on January 20. Marty has a wealth of experience in agile development, particularly TDD, and it will be valuable for people to get both our perspectives.

So, you want to be a change agent

Most software developers would say that they're not interested in being a change agent, that all they want is to be left alone to do their own work. In one extreme case I had someone tell me that they actively didn't want anyone else to learn how they worked, because that was their individual competitive advantage!

The trouble with this model is that most of us work in teams, even if the team is virtual and distributed, and most teams agree that they need to have consistency or, oh the horror!, standards. That means that if you come up with a new idea, you'll frequently need to convince other people to go along with it, or at least not oppose it, so you need to be a change agent.

The first thing to realise as a change agent is that you can only achieve so much. I think of myself as having a limited amount of change capital, that I need to spend wisely. Some changes have relatively low benefit, but require so little investment that you can and should do them straight away. On the other hand, some changes will have enormous benefits but will be difficult to achieve and may make the team resistant to further changes - this is frequently the case when a manager forces a change on a reluctant team. You need to pay attention to the return on your change capital investment, and investment it appropriately. Another common mistake is to try to make many simultaneous changes, spreading change capital thin and putting all the initiatives at risk. Successful changes generally depend on some minimum investment, and if you're not willing to make that investment you're better off doing nothing at all. Also, although some people are more resistant to change than others, everyone has a limit to the number of changes they can deal with and at some point people are liable to say "enough!". Flexibility is important, but so is stability and predictability and we need to make sure that we have the right balance.

So regardless of the quality of your approach, which I'll talk about in another post, you also need to pay attention to the quantity of change.