Quality 101
Yesterday was maintainability day and today I’m continuing through the basics of building software by tackling quality. Quality is a massive, massive topic encompassing practices, unit tests, automation, measurement, environments etc etc and clearly we cant talk about all of that in any single post. Lucky for us we’re talking about how you shape your thinking to make sure you’re always dealing with quality in the most appropriate way rather than any of these quality solutions. Oh and let’s insert my usual comment about user stories and establishing the habit of thinking about the business value of an idea rather than just raw requirement…
Let’s cook up a user story for quality replete with “as proven by” clause:
As the CTO, I want to represent high quality software following a distributed and decoupled architecture, So that we can leave behind reactive work and our engineering activities can be solely focused on adding value, As proven by appropriate and justifiable answers to the quality questions.
So what does appropriate and justifiable mean to quality? You need to consider a feature’s usage and the risk profile associated with it. What’s the business impact of bug? You will probably want to treat a feature that calculates the money a user is able to withdraw very stringently. You may quite possibly be less worried if your content carousel stops cycling fresh promo material for a while – you can fix that when you’re good and ready. Other things to think about are how many other people’s hands this code is likely to go through and what the feature’s planned shelf life is.
To help make sure you’ve covered your quality bases ask yourself:
- What is the anti-spec and how have I coded for it?
- Does my feature have tested and checked-in unit tests?
- How does my feature behave through a different user journey?
- Have I produced clear, readable documentation?
- Have I complied with any applicable design patterns?
- Do my comments and syntax make sense and match my documentation?
- Can I remove any lines of code?
- Will I be proud of this code if someone else reviews it?
If you can satisfy yourself with your answers to these questions you’ll be well on your way to reusable, supportable and easy to understand software.
