The Joke Is On Us

This xkcd cartoon was posted by a friend on facebook and it got me thinking about dev attitudes. The original article if of course sarcastic, but it dit get me thinking, even a little sweaty, so here goes.

Are we truly the only "profession" that considers joking openly about slacking off to be OK? Do doctors joke openly about killing patients? Do lawyers post amusing blog entries about misrepresenting clients or lying in court? I doubt it. I don't know who said it (it wasn't me: I'm paraphrasing someone, possibly Tom Gilb but don't quote me), but we will NEVER fully accept responsibility for our work until we are NOT PAID for doing it wrong, and until such a time, we can't count ourselves as professionals.

There was a debate on Slashdot a short time ago about whether software development could count itself as an engineering discipline: It was inconclusive, but raised some interesting points about accountability and consequence. We aren't really held accountable for what we do as software developers because we've nothing to lose if we get it wrong. For a chartered engineer, it's all a bit circular, but it goes like this:

• An engineer can be held accountable because of their chartered status.
• This is something they can't afford to lose, because without it they become less employable.
• Employers want (and need) chartered engineers so they can hold them accountable.
• Go around again...

It's not purely about what happens if someone dies (not all chartered engineers work in areas where this is a top-line issue!) as many contributors to the Slashdot debate suggested, it's a lot to do with the threat of being thrown out of the club. (Interestingly, most engineering institutions have Royal Charters, rather than parliamentary statutes (like say law or medicine), so an engineer is not tried in a court if he/she is in breach of their institution's bye-laws, rather it is "tried" internally).

So, although I found the cartoon funny (and they really are on xkcd; this bond/kinetics one has to be my favourite), the sarcasm is just too close to the truth for comfort.

Kaizen 5S and Software Engineering

So today our quality manager, Juliette , talked to us about 5S: one of the chief constituents of the Toyota "Gemba Kaizen" mantra. This was an eye opener: not a road to Damascus moment, but a little light went on for me. Not only did I start thinking, "yes, we really could benifit from a physical tidy up in dev", but I started thinking about the higher meaning of the 5 components of 5S in relation to engineering practices in general and therefore what (if anything) they might mean for a development activity.

You'd think that this would have been discussed at great length, but - maybe it's poor search technique on my part - there doesn't seem to be much out there at all on this subject.

More to follow on this as I organise my thoughts and note them down...