The other evening Jenny and I were trying to work out the principals of Double Entry Bookkeeping from an old accountancy textbook – as you do.

I was getting stuck on the concept of The Cashbook: when money comes into the company it should be entered as a debit in the cashbook, and when money goes out it is entered as a credit. I couldn’t get my head round that until it struck me that The Cashbook represents the rest of the world: the company gains £5000; the world loses £5000.

What a wonderfully elegant concept!

One of the world’s last surviving cargo cults is celebrating its official 50th anniversary on Tanna island in Vanuatu. From the BBC:

At the base of a sacred volcano in an isolated corner of the South Pacific young men play the “Star Spangled Banner” on bamboo flutes. Every February they parade in old US army uniforms with wooden weapons. Others go bare-chested with the letters “USA” painted in bright red letters on their bodies. Nearby, a giant Stars and Stripes flutters in the breeze from the main flagpole.

Afterwards they fire up their laptops, set all their local variables to null on declaration, replace all their inline strings with constants, and ensure that database access takes place only through stored procedures.

I thoroughly enjoyed London XPDay 2006 (much better than 2005). A great session was Lasse Koskela’s Resistance as a Resource Workshop. I liked it so much, I stole the workshop(*): I’m running the Agile Scotland session on Monday February 19th, Resistance as a Resource..

The core of the event is a simple brainstorming technique that facilitates reflection and discussion on dealing with resistance we have met, are meeting, or have given. Reflection and deliberate practice is how we build intuitive skills (Gary Klein, The Power of Intuition).

Details for the event are here.

(*) Ok, I asked Lasse if it was ok if I copied the workshop, and he said yes.

Eric Evans via Project.ioni.st

A lot of overengineering has been justified in the name of flexibility. But more often than not, excessive layers of abstraction and indirection get in the way. Look at the design of software that really empowers the people who handle it; you will usually see something simple. Simple is not easy.

If you’re being measured on the lines of code modified during user-testing and production, then the temptation will be to cover all the bases and massively over-engineer the code.

Anthony has a written a comparison of a few Rails templating options, ending in a compelling recommendation of Markaby. I do find the ”<% %> syntax ugly, and with more and more content generated by helpers there’s a lot to be said for a whole-Ruby option.

On the other hand I would hesitate. With the majority of the community, and especially the core team, using rhtml, and given the rapid pace of change to the framework would put me out on a limb. Tempting, though.

Dave Snowden:

1. The attempt to introduce conformity seems to play to the desire of senior executives for control, and the near autistic need of IT departments for neatness and order. Imagine what they would say if Government mandated that we only drive one type and colour of car.
2. Mandating a single tool always means a lowest common denominator approach. No one’s needs are fully satisfied, irritations arise, use declines, ad hoc alternatives proliferate.
3. The argument that a single tool is needed to ensure that people can share knowledge across silos is a nonsense. If you make sure that you use a tool whose database can be open to HTML links, or which can publish material then sharing between different systems is easy. OK you should lay some rules down to ensure interoperability but you do not need to mandate one tool. This may have been true ten years ago but no longer.

Nobody but you cares about the reason you let another person down.

Weinberg’s First Law of Trust, The Secrets of Consulting

Trust is simple. If I trust you, it means that I can rely on you to fulfill your commitments. It has little to do with honesty or intentions: if your record is one of not fulfilling commitments then, regardless of the reasons, I’m not going to trust you.

You only establish trust only by having a record of keeping commitments.

Don’t make commitments you can’t keep

You need to be conscious of the commitments you do make, and realistic about the environment and your own abilities. You also need to resist the pressure to commit to impossible deadlines; this can be very difficult especially if you are under pressure and want to appear co-operative. A trick I often forget is to just say “I want to be co-operative, but I don’t want to commit to something I may not be able to fulfil. I need more time.”

Do make commitments

It might be tempting to err on the safe side and avoid making commitments. You’re not losing trust, but you’re not building trust. Ali Law talked about trust a few years ago at an Agile Scotland presentation: he tells his consultants to build trust gradually with a client, beginning with making and fulfilling small commitments.

“I’ll definitely get those accounts to you” is too open ended. I like to give (and make a note of) a specific date or time for things. If I say “I’ll get those accounts to you by the end of Friday”, then it is clear when I’m in breach of my word.

Negotiate

The route from unreasonable demands to to commitments that you can keep is by negotiation. That’s a skill I need to work on.

Be clear about what is expected

Most fall-outs I’ve had with clients and colleagues have occurred when my understanding of an agreement differed from their understanding. It’s worth looking for ambiguities and getting things written down. An email “just to confirm what we agreed…..” may be sufficient.

Give bad news early

If you’ve made a commitment you can’t keep, then the earlier you break the news the less bad it’s going to be for you. This too, is hard. If I’m not being self-aware I can easily fool myself that I’ll make up for lost time; I don’t think I’m the only person that does this, either.

Update: replaced “Secrets of Consulting” book link for a more trustworthy one.

Recently I was talking to a friend who works for a corporate. A single metric of “development efficiency” is to be used to measure the entire massive software development effort. It’s based on a count of altered lines of code during testing and production (plus a shot of cyclometric complexity). The fewer lines of code that change “later in the lifecycle”, the better the productivity score. This might be an ok measure, if Waterfall was a valid development model.

sigh

“No, sorry. We can’t accept your business-critical change of requirements. It would play merry-hell with our productivity metric.”

sigh

Yet again I’m reminded of the drunk looking for his house keys under the street lamp. He’d dropped them in the alley, but it was too dark to find anything down there.

sigh

If you’re hell-bent on using metrics, at least hire Tom Gilb. Then you’ve got a chance of finding something useful to measure.

Inspired by Gary Larson’s “”http://www.flickr.com/photo_zoom.gne?id=153603564&size=o">What we say to dogs"