Presentation at Melbourne Patterns Group

I'll be doing a presentation on the Visitor pattern at the Melbourne Patterns Group on Wednesday. I've attached the announcement below (cutting out the bit that said what I was talking about - oops!).

---

The next patterns group meeting will happen on March 7th at the usual time and location: 6:30 pm at ThoughtWorks Office, Level 11, 155 Queen Street, Melbourne 3001. Parking should be
available near the building.

Please let me know if your coming for the meeting so that I can arrange for the pizza. You can rsvp by forwarding this email to sreeni@gmail.com. Since the building entrance is locked from 5:30 pm, myself or a fellow ThoughtWorker will be patrolling the entrance between 6:30 and 6:45 to let people in. Please call me at 04 3396 3725 if you are left waiting.

Cost of change

In software development we talk a lot about the cost of change. Cost of change is also a hot topic at the moment - how expensive will it be to reduce our carbon emissions? What will the impact on the economy be? So I was interested to read this in The Undercover Economist:

"Ask the polluters and they will tell you that reducing their pollution is like stopping breathing - it would be very expensive to stop, so somebody else should make the changes. But it's not really hard to find out the truth. Regulators can find out how much it costs to reduce pollution by telling people to either change their ways or pay a charge. Watch which decision they make. Judge them by their actions.

The EPA tried this in the case of sulfur emissions. They set up an auction for the right to emit sulfur dioxide, which causes acid rain. Polluters were given a quota of emission permits and could either buy more permits in the auction or reduce their emission by shutting down, installing sulfur scrubbers, or buying cleaner coal. When the EPA simply tried to tell them to install sulfur scrubbers, the power generators argued that it would be very expensive to do so, and they lobbied hard to stop the mandatory regulation. Even the EPA estimated that the cost of reducing sulfur dioxide emissions by one ton would probably be in the range $250 to $750 and might be as high as $1,500. But when the EPA conducted the auction in 1993, very few polluters made high bids. The companies had been exaggerating their costs. By 1996 permit prices had fallen to $70 a ton, and even at that price many polluters were buying cleaner coal or installing scrubbers rather than buying permits to continue polluting.

The regulators discovered that getting rid of sulfur dioxide was so cheap that few people were willing to pay for the right to keep producing it. ... The clever thing about the auction was not that the sulfur emissions were reduced - that could have been required by law - but that legislators all over the world found out how much sulfur scrubbers really cost. It created a basis for further legislation: not making rules in the dark, but in full knowledge of the (modest) cost."

So how would this work in software? Instead of telling people to reduce their cyclomatic complexity, I'll sell my teams some CC permits and see who bids for them and how much they pay. Same thing for test coverage. How about LOC as well? Ok, at some point we need to conscious of the Law of Unintended Consequence, but I like this idea a lot.

Design Improvement Workshop

We just took our tenth bid for the Design Improvement Workshop on March 24. We'll continue taking bids until midnight March 17, moving up in $50 increments. Remember that ties are won by the person who bid first at that price, so it's an advantage to bid early!

I'm really looking forward to seeing everyone on the day - I think this will be a great workshop.

Update - One subtle point is that increasing your bid doesn't necessarily increase what you pay - the final price doesn't change until everyone increases their bid.

Tools of Trade?

I came across this post, suggesting that developers be responsible for their tools of trade in the same way that mechanics are. I guess it caught my eye in part because of the picture of a Herman Miller chair. It turns out that I have one of those chairs, and there have been times when it's become my office chair and people have said "when do I get one of those?", and my response has been "when you buy one for yourself, just like I did". I've had it for at least 12 years, I think it's been a great investment, and I don't expect I'll ever work for a company that will buy me one. On the other hand, computers are (for me at least) consumables that don't last more than a year or two, even if my accountant wants me to depreciate them over three. Who should contribute to each of these, how, and how much?

I'm fascinated by the underlying theme because I think it will be relevant to things that Cogent does over the next few years. At the moment the majority of our work is consulting and the vast majority of the revenue goes back to the consultant who earned it. The accounting is pretty straight forward, but we're starting to look at different things (the EAT program for example), with different people contributing to different initiatives, we're also about to become liable for payroll tax. What's interesting to me is that keeping the books open and the accounting "fair" is already stretching my knowledge of both accounting and my accounting software. Marty and Simon are off thinking about software and training, and I'm thinking about accounting automation!

Marty and I will be talking some more about financial aspects of Cogent later in the week, and discussing some fairly simple models. This is all new to us, and we'll no doubt struggle. If you're interested in hearing more about this side of Cogent add a comment or drop me a line and I'll blog more about it.

Let's talk about tests, baby...

I just finished another TDD workshop, and I'm sitting in the airport waiting for my flight. As usual, I tried to emphasise that a single test should test one thing, and one thing only. As usual, people were having trouble doing that, which is perfectly understandable if you've only encountered the idea of TDD a few hours ago! To help people, I suggested that they articulate the objective of the test to their partner - "This test checks that ....." - and that if their description of the objective include "and" they should think about replacing that test with a number of more tightly focussed tests.

I also went a bit further and suggested that if the description could be expressed succinctly as "When X happens, we get Y value", then they were talking about a state test, and if the description could be expressed succinctly as "When we do A, B happens" then they were talking about an interaction test. I haven't tried to verify the approach yet, and I'm sure it won't be a blanket rule, but it seems like a reasonable heuristic. Since I don't get to program much these days, I'll look forward to feedback from people who do. :-)

Hybrid car or carbon offsets?

I'm in the market for a new car, and strongly motivated by Tim Flannery's "The Weather Makers" I started to do the research on buying a hybrid car. Here in Australia that really means either the Honda Civic or the Toyota Prius, which start at $32,990 and $37,400 respectively. Since I particularly want a hatch, it's really the Prius. This is a fairly substantial margin over what I'd normally pay for a car - my current car is an Astra which my wife and I have found to be great value, and if we replaced that with the new model, which starts at $21,990. Not equipped to the same level as the Prius, but enough to keep us happy :-)

Fifteen thousand dollars is a pretty big margin so out of curiousity, and prompted by Marty's post on carbon neutrality, I decide to have a look at what it would cost me to offset my carbon emissions rather than use a hybrid vehicle. The results were a big surprise to me.

I used two different sites to calculate our family carbon debt. I assumed a new Astra manual, which uses 7.4 L / 100km (from the Australian Green Vehicle Guide), and that we do 20,000km per year. We already use green electricity, and we use an average of 150Mj of gas per day over the year (the vast majority in winter) for hot water, cooking and heating. I've also assumed that I do 3 business trips to Brisbane in a year, we take the family to Sydney once a year to visit grandma and to the equivalent of New York once a year to visit grandpa. The two sites gave comparable results, but the best breakdown came from Greenfleet. Our carbon debt is approximately:

• 3.34 tons from the car


• 3.51 tons from the house


• 41.07 tons from air travel


• 47.92 total

What surprised me is that the contribution of my air travel is over 12 times the contribution of my car! The conclusion is that I need to participate in some carbon offset program, but the interesting part was the cost - to offset all this carbon debt at CarbonFriendly (whose shop sucks, just by the way) was going to cost about $1000.00, and the car part of that would only be about $70 per year, so why should I go to the much greater expense of a hybrid vehicle?

I'm interested to find out of anyone else has gone through a similar decision process. Logic tells me that I should forget about the hybrid and pay for the carbon offsets, but part of me feels like this is somehow cheating. What do you think?

Great Interview with Kent Beck

I frequently suggest that software development is a social problem, not a technical problem. Kent explores this idea in this interview, and shows that his thinking on the topic is clearer and deeper than mine!

Design Improvement Workshop

The January EAT workshop was a great success, so we've decided to do it again. I'm pleased to announce that Marty Andrews will be presenting our Design Improvement workshop on March 24. As with our previous workshop, we're limited to 10 places and pricing will be determined using an auction process. You can see the latest bids and access the workshop details on our
wiki.

Roles and titles

In general, I've been opposed to giving people titles on projects, especially titles such as architect, senior designer, or even tester. I've been opposed because I didn't want the titles to lead other people in the team to feel that they didn't have responsibilities in these areas. My preference is that everyone feel responsibility for every aspect of the project - that the team own all the problems.

Of course people who worked with me at IBS are now saying "hang on, there were people with specific titles/reponsibilities", and there were. For each team we identified three different lead roles, each of which required different skills sets. Let's say that they were design-focussed, people-focussed, and process-focussed. The argument was that when everything was working well things were a team responsibility, but if something went pear shaped I, as a manager, wanted to be able to go to one person and say "what's going on?" - I was trying to handle the failure modes. I don't think this worked as well as it should have, mainly because in my time at IBS I spent most of my time working as a recruiter or a fire fighter, and not really much as a manager (and I need to take the blame for that).

So where am I going with this? In the project I'm currently involved with we have titles/relatively strong roles, and I'm enjoying it. We have two people in the BA role, a test manager, an architect, and me (I'm nominally the development lead, but I haven't really figured out what I do that isn't covered by someone else yet, but I'm sure I will eventually). What I'm enjoying is being able to leave certain things to other people - in some sense to be able to flick them over the wall and not think about them at all. Now don't get the impression that we're sitting in bunkers lobbing artillery shells - that's definitely not the case. There's plenty of collaboration, and we definitely help each other out where we can, but we're also willing to trust other people to do their bits, ask questions where they need to, and keep the rest of the team informed (this is helped by all being in a project room and not having cubicles).

Reluctantly, I think I was avoiding titles because I didn't trust everyone on the team. Not in a suspicious, I-have-to-keep-an-eye-on-you kind of way, but at a level I wasn't really aware of. Still, if you're read the first paragraph carefully you can sense the distrust, either towards people's sense of responsibility or towards their technical ability. I think there are certainly times when that's appropriate - if I had a team of grads I don't think I would give them some roles and 'flick things over the wall'. I'd want to assign tasks, monitor them fairly closely and see how things went. I think that my mistake was trying to create a blanket rule, rather than assessing each case individually, which is a manager's job after all.

If I get a chance to do this again, I think I'd prefer to more formally acknowledge roles within the team. If it turns out that one person has all the lead roles, then lets say so openly - it certainly tells us a lot about the current skills mix within the team and how we need to change it. If a team is mature enough to handle having no formal roles, I think they'll be mature enough to handle having formal roles as well.

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.