Coding and Dismantling Stuff

Don't thank me, it's what I do.

About the author

Russell is a .Net developer based in Lancashire in the UK.  His day job is as a C# developer for the UK's largest online white-goods retailer, DRL Limited.

His weekend job entails alternately demolishing and constructing various bits of his home, much to the distress of his fiance Kelly, 3-year-old daughter Amelie, and menagerie of pets.

TextBox

  1. Fix dodgy keywords Google is scraping from my blog
  2. Complete migration of NHaml from Google Code to GitHub
  3. ReTelnet Mock Telnet Server à la Jetty
  4. Learn to use Git
  5. Complete beta release FHEMDotNet
  6. Publish FHEMDotNet on Google Code
  7. Learn NancyFX library
  8. Pull RussPAll/NHaml into NHaml/NHaml
  9. Open Source Blackberry Twitter app
  10. Other stuff

Fixing Bugs and User Perception - Getting the Best of Both

I've had a couple of days out of the rigours of sprinting and developing code, a chance to wind down and do other things for a while. "Other things" has so far been bug fixing and planning for the next sprint. Now ordinarily, bug fixing isn't a great love of mine, I don't think it's a passion for many developers I've come across, but I think I'm learning to love it, and here's why.

In the process of fixing bugs, I've had a healthy reminder that there are real users at the end of our processes, that these people don't get to communicate with us geeks nearly enough, and of course it is good to be fixing stuff that causes people pain.

Bug Fixing - Why the Trepidation?

It keeps coming round, over and over. Developers do not like to fix bugs, developers definitely don't like investigating bugs. It's probably because bug fixing's not seen as cool; it's not a place to learn ninja new skills. (Though I could argue I've learned some ninja Excel skills along the way!)

Developers want to be developing new stuff, they're bored with the stuff they build last year. They're bored with the code base, they're bored with the repetitive bugs. (Not ANOTHER outstanding balance!)

And there's another problem - if the buggy code is more than, say, a year old, compared to where the team are at today, the code will suck. It'll either have no test coverage, or no effective logging, or no design-by-contract, or be littered with empty "catch (Exception)" blocks, etc, etc. Today's bugs are like the ones from "A Bug's Life", the ones from the old days are more like something out of "Starship Troopers".

I can't help you with the fact that old bugs are crappy bugs - sorry! But maybe I can help you make bug fixing a little more rewarding.

Meet the Users - Your Biggest Fans

So what to do? My solution is to forget about all that boring stuff, and get back to why fixing bugs matters. Fixing bugs matters, because it's these bugs that absolutely infuriate your users.

Your apps should let your company's employees move mountains. While they're engaged in the moving of said mountains, if your software landscape is anything like ours, the odds are they're constantly dealing with the fact that if they press a certain lever the wrong way, the bucket falls off their earth mover. Or if they're going up a hill and they're not careful it dumps a big pile of dirt on top of the driver's cabin.

Small bugs in an otherwise magnificent piece of software can get some real tension building up in your user community. Diffuse that tension. When you get the chance to fix bugs, go and have a chat with the users who are having problems. Ask them to show you what they did and how, make it clear to them that these bugs are as painful for you as they are for them, and that you're doing your utmost to sort them out.

The Users are doing WHAT!?

Getting to know your users isn't all about the touchy-feely "the software's a bit shagged, we're fixing it, humble humble humble...". There's the added benefit that while you're mingling in user territory, you sometimes see things that are REAL eye openers. I remember conversations with users that have gone something like:

Me: "Okay, so can you just finish off that order please?"
PC: Red screen of death
User: "Oh yes, that happens every evening after 6, we just click Back and retry until it works"
Me: *head-slap* "No problem, we'll look into that".

To be fair, this is survival instinct, I can't fault a user for doing this. But then there're the conversations that go:

Me: "I understand you've reported a problem saving this order?"
User: "Yes - I'm not authorised to amend payment details, so I manually key in the URL to get me to that page, and before today it used to just work..."

The Summary Soundbite

No matter what the people who pay the bills think, I don't think your software is any better than your users think it is. If your users think your software sucks, they'll either refuse to use it, or use it such a heinous way that it's crippled anyhow. Make sure your users are happy! Talk to them, ask them questions, make them realise that they're your top priority.

But don't worry, when you're back in fellow developer territory, it's probably still okay to brand them a bunch of idiots. I won't tell.


Permalink | Comments (0)

Add comment

  Country flag

biuquote
  • Comment
  • Preview
Loading