Bugs part 2: Towards perfection

Published on January 6, 2010

There is an expectation placed on developers – and pretty much everyone else – that they must strive towards perfection. Failure is not an option. There’s a general attitude anyone who makes mistakes is not good enough. When mistakes are made, heads should roll.

There’s a nasty cycle where mistakes are ignored or at least forgotten about. First, we all assume that we are good at what we do. When mistakes (inevitably) happen, we assume therefore that they’re someone else’s fault. If the system does not behave the way the customer expects it to, we assume it was poorly specified. If a bug makes it to production, we assume that the tester failed. Even if it’s decided that the bug is our fault and our fault alone, we assume it was a one-off mistake – a bad code day or whatever. Or else assume that it’s the sort of mistake that we’d have made a year or two ago but we’re too experienced to let that sort of thing happen again. Either way, we assume it won’t happen again. Because we’re good at what we do.

The big problem is that we assume that we’re perfect. We’re not. There’s a simple test: Have you ever made a mistake? If the answer’s yes, you’re not perfect. If the answer’s no, you’re a liar. And not perfect.

Bugs part 1: Don’t mention the war

Published on December 21, 2009

My wife – a doctor – has been looking recently at safety systems in the aviation industry and their applications to the health service. In particular, how errors are reported and followed up. Apparently, NASA’s Aviation Safety Reporting System (ASRS) is the way to go. Every industry wanting to improve safety and reduce errors looks to NASA and ASRS.

Software is usually not quite as safety critical as aviation or health but one of the key targets for a software business is quality. Even if people would not die as a result of buggy software, we usually want high quality bug free software as the long term cost is lower and so profits are higher. Yet I often find the general attitude to bugs and mistakes is all wrong. The standard attitude is:

My boss wants bug-free software. Bugs make my boss unhappy. Therefore, my boss will be happier if he doesn’t know about the bugs.

It’s slightly simplistic perhaps, but who can honestly say that they’ve discovered some obscure bug in the system and felt absolutely happy about bringing it to the attention of management or other developers? Have you never considered just conveniently forgetting all about it?

JUnit testing Hibernate and Spring

Published on November 15, 2009

Here’s a nice recipe for unit testing Spring configured Hibernate. It allows me to neatly test my Spring configured DAOs and reuse a lot of the Hibernate Session and Transaction configuration beans from my production code. This saves having to rewrite it for my tests and also makes the tests more realistic. I’d rather test my production code rather than use mocks as far as possible.

Continue readingJUnit testing Hibernate and Spring

Less is More and other cliches

Published on November 8, 2009

We’ve recently released the latest version of our product. A relatively minor change – just a couple of months dev plus same again in QA. As we get closer to the release date, we’re less inclined to make major changes to the codebase. Unit tests or no, it’s just not appropriate to perform major refactor work in response to a bug report the week before release. So we tiptoe round the code, tweaking this and adjusting that with only one eye on how maintainable it will be in future.

For example, a few days before release I found that a few text fields on a web form were completely redundant. Whatever they wired up to has been replaced by something that can work out the value for itself. Should I have removed the text area? I was 99% sure it was safe to do so, but I must have made judgement calls like this 80 or 90 times in my career. I’m due to get one wrong soon. And the consequences would be another phase of QA, making the project late or (worse) releasing a broken product.

The result of this is that beautifully designed code is written during the dev phase, it’s carefully rationalised and refactored. Should anything be found not to hang together quite right during QA, out comes the gaffer tape.

Installing WordPress

Published on November 1, 2009

This is post number four and I’m going off topic already. This post is a technical note on how to install WordPress on a desktop PC.

After installing WordPress on my hosting service (hosted on Easily if you’re interested) I wanted a copy on my home PC as an offline backup and to generally fiddle with. As I’m likely to zap my PC soon (Vista is dead, long live Windows 7) , I’m keeping a note of how I did this.

Mr Tidy Socks

Published on October 25, 2009

I was watching Wall-E again recently. It’s a wonderful film and I’m astonished that something that well made was a mainstream success. I really like the bit when Wall-E is sorting through the day’s interesting items. He finds a spork and goes to put it into his little cutlery collection. At first he goes to put it with the spoons, then the forks, then the spoons again. Eventually he gives up and puts it in the middle by itself. I thought that was sweet and I recognised myself in that.

I’m of the opinion that that sort of thing makes a good developer. The urge or compulsion to sort and categorise things. Is it a spoon? Does it have spoon-like qualities? Could I perform standard spoon operations on it? Or for that matter, where do I file the latest Circus Devils album in my CD collection? C for Circus? P for Pollard, Robert (it’s one of his many bands)? G for Guided By Voices (it is / was his main project band)? Or just bung it in wherever it fits on the shelf like a normal person?

Bean introspection

Published on October 20, 2009

Spotted this nasty little quirk today – not for the first time. Every time I see it I want to get angry at someone but I’m not quite sure who.

What’s wrong with this list of properties?

private String name;
private String address;
private String eMail;

Nothing immediately obvious perhaps. Here are the standard generated getters and setters (signatures only):

public String getName();
public void setName(String name);

public String getAddress();
public void setAddress(String address);

public String getEMail();
public void setEMail(String eMail);

All perfectly valid. Now, given these auto-generated getters and setters, what names would standard bean introspection derive?

name
address
EMail

Hang on, what happened there? How did my eMail property turn into EMail?

Why? (Part 1)

Published on October 16, 2009

Sure, lets start with the big question first. Software Development – why? Why write about it? Why do it for a living? Why do we need software developers?

True to my nature as a software developer, I’ll divide and conquer. One question at a time please. And true to my nature as a code monkey, I’ll start with the easy bit.

So, easy question first. Why write about software development?

As I was walking home along the Clyde one evening, thinking vaguely about what I’ve done at University and at work I realised something a little worrying:

I’ve forgotten more than you’ll ever know.

Don't Panic! Posts