Thursday, 8 November 2012

Quality vs Quanity - Where is the Value?

"We want more!!" - A common cry from businesses, generally aimed at their own IT departments, and usually met with groans from developers. The problem here is that quite often the rest of the business has no true understanding of what "more" actually is. On the face of it, they just want more features, more frequently. They don't generally understand the underlying work that goes with software development and, more importantly, they don't care.

Now the challenge here is to try and get a grasp of what it is the business is asking for more of. Is it simply more features? Do they want more quality? More efficient development teams? Over the last few years I have learned, quite possibly the hard way, that there are two things that they are asking for more of. It boils down quite simply to a question between quantity and quality.

First and foremost is the desire for more features. They want the software to be as up to date as possible and would change something every day if they could, and they will drive a development team as hard as they can given the opportunity. Their main motivation is to keep their products up to date, or even lead the market. This focus on pure output, with apparent disregard for quality, can yield great results in the short term, but is unsustainable in the long term. As low quality software expands and evolves, the overhead for maintenance and improvements increases over time, and if not addressed can end in a point where you spend more time on maintenance rather than new features. Once you get to this point, the business will start to ask questions as to why things are now taking 2, 3 or even 4 times longer than they once did. This is not a nice situation to be in and getting out of it can be a very difficult task - the business will need to give you some time to invest in improving the quality, or even take the hit of allowing things to be re-written in the correct way. As with a lot of things, prevention is much preferable to a cure - and working with the business from the beginning in order to work the quality in at the start is the best way to go.

Most developers (at least the ones I tend to know and work with) want to produce quality software that is reliable. They use techniques and methods with a view to achieving this aim. Things like wrapping tests around functionality, writing code in an Object Oriented way, keeping things simple, and Pairing are fantastic ways of improving the quality of code. On the face of it, the business will see these practices (especially TDD & Pairing) as an overhead that will result in development taking longer. The usual argument is that if some work now takes 2 developers instead of 1, surely the amount of time to develop it has been doubled. The hard bit of this is showing the business the value in using these techniques. From my own experience, even seeing the cold hard facts of what happens when you don't use these techniques is not enough to convince some people. Fortunately, you cannot argue with metrics and statistics. If you record good metrics for doing things both ways over a given time period, you will be able to visualise the long term gain that this will return (see previous post for more info on why metrics are so important).

In conclusion - if the company you work for only wants to exist in the short term and does not have any long term ambitions - then they are making the right choice in not wanting to invest in quality. However, I highly doubt that any company would not have long term ambitions - and as such I would strongly urge you to work with your business in order to factor in the quality now. Long term quantity relies on constant quality - therefore if you always want the quantity, you are going to have to invest in the quality now.