Software Development Archives

Coding in the Age of Distraction

Published on April 25, 2013

I must have seen a hundred blog posts suggesting that the best way to become more productive is to minimise distractions: Switch off IM, disconnect the phone, block out quiet time, get a private office and so on. While I’m sure that these would be of benefit, sometimes distraction is inevitable. I could switch off IM, email and my phone but I happen to work at the desk next to my boss. Convenient as it may be, my boss does not come with an off switch. Also, priorities happen. I may believe that my ‘in the zone’ coding time is golden and must not be interrupted on pain of code diva tantrum. However, if the production server goes down then scheduling a fix next week is just not good enough. Finally, I do on occasion like to stop work for the day and go home. A good night’s sleep is definitely a distraction from work but also I think quite important.

It’s certainly worthwhile arranging your environment and schedule so as to minimise distractions. But it is also important to accept that distraction will happen and to plan for it.

When it’s time to move on

Published on October 12, 2010

You’re a problem solver. You’re one of these people who will pick up a rope that’s gotten all tangled up and spend an entire day untangling it because it’s a challenge, because it defies your sense of order in the universe and because you can. – Sometimes I try to picture you sitting on a beach with absolutely nothing to do… The picture always ends with your head imploding.

— Delenn, Babylon 5 – Epiphanies

In an attempt to stop my head imploding, I’ve decided to leave my current job. I’ve spent the last three years solving some great problems and untangling a whole heap of stuff. Just recently I’ve begun to feel that I’ve gotten everything in order and there’s just nothing left to straighten out.

Bugs part 3: Don’t shoot the messenger

Published on January 17, 2010

I’ve spent the last couple of posts discussing developers’ attitudes to bug tracking. More often than not, it could be better. In this third and final post on how developers deal with bugs, I’ll discuss how we might improve our attitudes. Forgive me, but just this once I want to go all hand-wavey and go on about positive attitudes, constructive criticism and so on.

Would it come as a surprise to you if I said that developers see bugs in a negative light? Yes, when we see other people criticising our software, telling us that it’s not good enough, saying “no mate, it’s broke”, we take it as a personal insult. I can’t imagine why.

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?

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.

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?

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.

Category: Software Development