Software systems are being delivered to our customers at an ever-increasing rate. How can we keep up with the pace whilst still maintaining the quality of our code? I will demonstrate over a series of three articles how by focusing on the customer throughout our delivery cycle we can deliver reliable working software with confidence, reduce the number of defects, reduce our delivery timescales and ultimately save money. You may think this is nothing new, and that agile development has long since answered this question. However, even in the agile world there are loopholes which allow us to bypass the customer. Leading us to deliver what we think they want, rather than what they were expecting.
Writing shippable code is a daunting task. Ask yourself "Will my customers really be happy?" It's impossible to predict with certainty that a complex system with thousands of lines of code is going to be defect free enough for our customers to be happy. It's true, we know it's never defect free so we compromise with defect free enough. Our prediction is often based around the number of lines of code we have touched or written, the number of defects we have found historically per hundred lines of code and the average time it usually takes for us to fix a defect. This allows us to project and track against a find fix curve showing how after 100% code complete we are stabilising our system. We rely on prediction because of the uncertainty that is introduced throughout our development cycle by the circles of information hand-offs and the honest fact that we know we will produce a system which genuinely does have defects.
What if we could remove, dare I say eliminate, the ambiguity and reliance on prediction right from the off? What if we could produce with confidence shippable code? An impossible task? Several techniques used within agile software development (Test Driven Requirements, Test Driven Development, Coding by Assumption for example) can improve our confidence and quality of our code are still rarely used by many organisations.
Going on a Journey
Software systems are becoming more and more complex, though to our customers they have to appear to be becoming simpler and simpler. People are so much more aware of the time they spend immersed in our system especially in a day where every click counts . They demand to have simplicity whilst still interacting under the hood with ever changing technology, standards and protocols. Yet, we are still expected to keep up with their expectations, deliver on time, stay within budget and have a robust defect free system.
It used to be acceptable when applications failed or got stuck every once in a while but those days are long gone. How can we improve the system we produce so that it genuinely does what it is supposed to do without failing?
Imagine I'm going on a journey to somewhere I have never been to before. I'm going to take my family on a day out and we intend to have a lot of fun when we get there. My wife's expectation is that we will leave with enough time so that we can enjoy a full day, whilst still being able to get home at a reasonable hour to get the kids to bed. What do we do? It used to be that we just pick up a map, try to find where we are going to and mark out our route following the major roads. We'd guess as to how long it takes to get there based on our own personal experiences and suggest a set off and return time - job done. Though for me at least I would state that most places ended up taking 2 hours to get to, wherever the destination. In actual fact it takes longer, we end up getting there late, leave early and don't get what we wanted out of the day.
These days we go to our favourite internet mapping system. Key in our start and end points, the time we wish to leave, maybe adjust the route on screen to avoid certain roads and we get a very detailed plan showing exactly how long each stretch of road is, the time it should