Category: Software Development

On the Job Training as Knowledge Gathering

This week, I am being trained on an application which I am to build the next version of. Initially, I thought it would be a bit of a waste of time. I’ll be writing the all new singing and dancing version on a completely different platform, so who cares about being trained in the old one?

Well, it turns out I should. Being in a training room with other people who are also learning it is providing me with invaluable information. So what if I know how the app is working under the hood after reading the code base for the last couple of weeks? I have pages of notes on things that need to change that may have made it into the next version without this kind of feedback. I am watching how users – new and old – are using the application in its current form. I’m experiencing some of the strange niggles first hand.

This post isn’t to down talk the application as it exists now – like anything these days, it has its great points to. What this is about is being aware that just watching your end users – be they trainers or newbies – use your application is like a gold mine of information on what could be better, what actually works, what they want to see more of, and what they want to see less of. They don’t care about what’s under the hood. They just want to make their working day more efficient.

Although it’s bound to be time consuming, I can’t help but think that having user groups together to play with an app well before release in an observable environment will do that app more good than any number of revisions to a product specification. I’m not talking beta testing here, as what I’m experiencing now is active feedback on an application where the new ideas are still being collated. It’s something I’m going to be trying to push for going forwards in my own processes. It’s not a new idea. I’ve just never thought of applying the idea to a training scenario before. An established application in a training environment is certainly a great candidate for this treatment.

Going by the information that I have noted down after just two days, observing a hands on training session group is providing more value to me as a software and UI developer than any mass emailed questionnaire ever could.

Developer, Love Thy QA.

I suck at testing things. Always have. I keep trying to be better at it, but I’m just flat out awful at it. I don’t have that twisty way of thinking that would cause me to try and use something in a way that doesn’t seem logical to me.

There have been a few times in my career where I have been in a position where I was expected to fully test something that I’d been heavily involved in. It is after these experiences that I am convinced of two truths in software development.

  1. You shouldn’t be testing your own code. You get caught in a ‘pattern blind’ trap, because you coded that thing from the ground up. You know exactly how it’s supposed to work, and it’s incredibly difficult to conceive anyone attempting to use it in a way that you have deemed stupid in your own head.
  2. A good QA is worth their weight in platinum. They care enough about the quality that they will make your application sit up and dance until they break it. And they’ll break your application in all sorts of exciting ways in which you could never imagine.

We’re in a world where deadlines seem to trump quality. This is really bad from a consumer perspective. To give an example – I no longer pre-order computer games, or even buy them on release day. I wait until the first patch comes out to fix all the issues with the game before I even think to throw money at it. This has happened with every single game I’ve been paying attention to for the last year.

As a developer, I want anything I work on to kick bottom. As myself, I know that inspite of my best efforts, a tester I am not. An aggressive QA person constantly bouncing something back to me, while demoralising, means that I have an extra set of eyes making sure that my app is going to kick arse.

A bad review can completely destroy customer confidence. Which is why, as a software developer, my alarm bells start ringing if I interview at a place where they proudly proclaim ‘We don’t have a QA team’. Those same bells start ringing when a team is pushing a tight deadline, and the first thing to be pushed back on the table (or sometimes off it all together!), is the QA.

Dropping QA should never be acceptable. Love your QA, because by doing what they do, they are covering your backside. Instead of dropping QA to meet a deadline, I think anyone who cares about your product would much prefer you to just push back the deadline instead.