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.

Monday, 15 October 2012

Perception and Fact - There is a Difference.

So here I go, the first of many posts (hopefully).

There are many ways that people progress through their careers, be it progression through a single business, or jumping from role to role in order to get to where you want to be. My experience is pretty much the progression through a single business, so this post is going to highlight the challenges that this has posed me, and how I have gone about tackling them. Hopefully this will help someone out there who finds themselves in a similar situation.

Now, I joined my current company as a junior. This meant I was still learning my trade, learning what was good and what wasn't. Learning what was acceptable, what would get me attention - be it the right or wrong type of attention. Through all of this learning, people gain a perception of you. This is especially true for the people in other departments who only get snap shots of you at work. I have found that this perception is especially difficult baggage to get rid of, but have been trying to do so for a while now. Whilst the people who work with you on a daily basis can see all the great things that you do, the customers just see snap shots of a young, loud, enthusiastic and sometimes brash young man telling it how it is. They see a young man having a laugh, keeping his team engaged and motivated and don't link it to the work delivered by the team he is in. They see someone not sat at their desk writing code. Whilst this may seem a little cynical, it is also devastatingly true.

In my role as a software development manager, I have a much closer working relationship with the people who take this exact view. Even more frustrating than trying to change these individuals perception of myself, is the fact that they have the same view of the staff in my development teams. Having suffered from this myself during my short career, it is something that I am quite passionate about working on and ensuring does not cloud the view of how my teams are performing.

The problem with all of the above is that it is simply based on the perception of individuals by individuals. A company with a culture that allows individuals to make decisions and changes based purely upon perception needs to stop and take a look at itself. They allow the company to be run purely with their emotion and little to no statistical data. Whilst it is invaluable to have the passion, desire, and drive to have a successful company, it needs the stats to go with it in order to truly delivery value. Without stats they will say that a team is not delivering enough and the team will be called upon to explain why. This is ultimately demoralising and not conducive to a highly performing development team.

Despite the views of people within businesses that I.T. 'aren't delivering' or 'could do more', the simple fact of the matter that all of this is based upon someones feeling, and can very rarely, if ever, be backed up with data. This is a very scary thought. Even scarier is fact that this isn't something that just happens in one place, but happens out there in a lot of companies. 

The move to driving changes and improvements out through the aid of actual statistics and figures can be a challenging one but, without them, how can you ever prove that what you do at work had a benefit.

The moral of this story, boys and girls, is that if you want to change something, you are going to need some way of seeing if its had a positive or negative effect. The only real way that you can do this is through the aid of stats and figures. This is the only true way you can have continuous improvements within the development teams, it is the same for the rest of the business. You have been warned.