A key realisation was that we need to ensure that quality is higher; quality is always a word which makes me think: What is quality? How do you define quality? I often think that quality is one of the most subjective words in software development. I’ve come to realise that quality isn’t just about how good the code is. It’s about meeting the customer expectations as quickly as possible – that’s the purpose of our job (the Agile Manifesto highlights this).
One of the key things to quality is that getting through system test shouldn’t be a chore. It should be a pleasant experience and the amount of back and forth between System Test and development is a good indicator of poor quality. (Note: this isn’t the only measure of quality; this article isn’t about code quality). This should be reduced to the minimum. This is twofold:
- It can cause friction between developers and testers.
- More importantly it ends up costing you a lot – of trust, and more importantly money.
I often wonder where I lost that skill or why I forgot to do it. After I graduated it all became about writing code and getting it in to production as soon as possible. It didn’t matter about the tests; it just mattered about getting the code out as soon as possible. How mistaken I have been. I must have cost companies a fortune; I’ve been for interviews where they asked, “How do you test code?” – press F5 and play around with edge cases was generally my answer. You could see their faces – “What about NUnit?”
Big admission I know. For me over the past couple of years I’ve come to realise that software development is all about learning, the faster that you can learn the more adaptable and more progressive you become as a developer.
It’s taken me about 6 months to get used to Test Driven Development, and get it (nearly) completely embedded in to my development practise. I now feel that I have a better understanding of how to write tests, and write better quality code as a consequence. This hasn’t been easy – it’s been hard work, changing the habit of my entire (semi) professional programming career. Write the tests first, and then write the code to make those tests pass.
It is amazing that it now “feels wrong” to be writing code which doesn’t have a test. How weird I wouldn’t have cared a couple of years back. It’s definitely been a learning experience and something that I am now keen to share with other professionals as well.
Once you become passionate about a technique it can quickly rub off on to other people.