So the Agile manifesto states that we want to uncover better ways of developing software and in the process we need to value “Working software”. If we are really going to value working software then we need to know when that piece of work is working and done. This now raises another very important question what is the definition of done? The simple abridged answer is that all the acceptance criteria have passed for that piece of work.

For a piece of work to be done we need to validate that it meets it’s acceptance criteria. How are we going to do that? Well we’re going to test it against each acceptance criteria, so the simple thing to do would be to run through each acceptance criteria and test it. And every time we complete another piece of work we need to check it against it’s acceptance criteria and then check all the completed pieces of work against their acceptance criteria to make sure we haven’t broken anything. If we keep following this pattern the effort to test our software is going to grow to mammoth proportions.

So being the pragmatic programmers that we are, we don’t want to repeat ourselves, do we? So we’re going to write our tests upfront and write our code to meet the specification set out in the test. Which brings me to my first point in answering the question, many developers see tests as an afterthought and are done at the end. Without those tests up front how do you know your code has ever met its acceptance criteria? Do you code and hope? This now leads me to my second point, you’ve proved your code meets it’s acceptance criteria and you can do it over and over at a click of a button. In the long run you’ve saved yourself and others so much time and hopefully in turn saved money.

We’re now creating software and we can prove it works and its done. But that still doesn’t totally answer why its the first to be dropped by your stakeholders. I think this is down to quality being over looked, the stakeholder is very conscious of the cost, time and scope parameters of the project but not quality and that’s down to us! We need to sell our stakeholders on the fact we’re professional craftsmen and we will not compromise on quality much like a construction engineer won’t on the foundations of a building. We need to explain there is a very good reason that we won’t compromise on quality, partly for the reason i have discussed above and many others.

I applaud you to make sure it’s known while scope, cost or time can possibly flex quality cannot. But make sure to support it with what benefit they will receive in return for fixing quality.

This was recently asked on my companies internal developer forum, i thought i’d take this opportunity to gather my thoughts as a forum post just won’t do it justice.