· software-development

Quality is what I work for

I’ve been reading the transcript of Joel Spolsky/Jeff Atwood’s podcast discussion on TDD/Quality and related posts on the subject by Uncle Bob and Ron Jeffries and while I guess it’s fairly inevitable that I’m likely to side with the latter two, what I’ve realised is that I get the greatest enjoyment from my job when we are writing high quality software.

Certainly delivering value to customers in a timely manner is important but if we’re not producing something that we’re proud to have written then I think we’re doing ourselves and our customer a disservice.

Taking shortcuts on quality in the short run might seem to give some immediate benefits but they don’t tend to last very long and nearly every time I’ve taken a short cut on something I’ve come to regret it.

Given this, however, what is it that high quality software means to me?

  • Code that adheres to the principles of object orientation so that when we have to make changes these can all be done in one place and without having to keep the context of loads of different classes in our head in order to make those changes. This means creating lots of small objects with single responsibilities and keeping behaviour and data in the same place just for starters.

  • Using the language of the domain in our code so that we don’t have to translate between the language the business use and the language that exists in our code. It’s amazing what a difference this makes and the amount of time we save by having everyone speak the same language.

  • Taking the time to think about how the problem we are currently working on fits into the bigger picture and coming up with a solution that not only solves the problems but doesn’t have a negative impact in other places. There is nearly always more than one solution to every problem and taking the time to analyse each of the options and then choose the most appropriate one tends to result in a better outcome.

  • Ensuring that we refactor our code into a state that someone else on the team can easily understand what is going on without having to spend a lot of time delving into implementation details. Using extract method religiously is the best way I know for achieving this. Writing code that just works is not enough.

  • Writing code that is well tested so that we have a degree of confidence that it is actually going to work when we put it in production. Zero defects is the aim, but if at the least we can ensure that bugs aren’t repeated then we are doing reasonably well.

  • Favouring a simple solution over a complex or clever one that is more difficult to understand. Writing simple code is much more difficult but when we aim for this the job of reading code becomes much easier and our team mates can understand what we’re doing much more easily.

  • Treating our tests or specifications with as much respect as we do the production code. If they are to act as part of the documentation of the system then it is our duty to ensure they are in good shape.

I’m sure there are more ways to assess quality but those are the ones that come immediately to mind.

If we are achieving the above then I tend to feel a sense of satisfaction in the work I’m doing. If not then I start to wonder what we’re doing wrong and try to find ways to get closer to my ideals where possible.

In addition to the above, I think we should be constantly looking for ways to improve the work we are doing as well as our approach.

Never settle.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket