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.