Part VI – What happens if we don’t have Tests
This results in what’s known as Technical Debt. But it’s only technical debt, if the business is aware of it and it is an actionable task whereby we know that at some future stage we can pay back this technical debt by fixing the known issues, in other words we are paying back the interest gained over the time we didn’t have tests in place. The longer the applications don’t have appropriate levels of testing, the more the interest payments mount up. Technical Debt is not a bad thing, as originally proposed by Ward Cunningham, so long as it’s communicated and known.
Cruft is a bad thing; this is for example badly laid out code that in the future could break an application, when trying to extend it further. Things like not obeying the SOLID principles can lead to cruft. Code should always do the job at hand, it may not be perfect, but as long as it is tested and proves within the context of the story that it does so, then this is fine. Code NEEDS to be correct, you can’t just hope it works out, like in the medical profession; you can’t just poke and hope it will be fine, as well as in construction, you need a solid structure.
Don’t ask permission to do your job correctly, use the Boy Scout Rule
Never make intentional mess, remember the boy-scout rule when approaching new code, and always leave it in a better state than you found it.
Your responsibility to Quality
Quality is everyone’s responsibility, no matter what the role; it is up to everyone involved in the application to ensure it delivers the right value to the end-user. Monitor trends, not points, its ok if our code coverage or cyclomatic complexity goes if we need to meet a strict deadline, so long as it is noted and planned to make it better.
Fin!
It’s all about continuous learning, feedback and a little pain. We learn from this as pain becomes a weakness leaving the CI/CD process. Software testing allows us to realise where we are failing and where we need to improve, by providing us with the feedback faster to allow us to learn and improve our continuous improvement, continuous integration and continuous delivery dream-line.
A Few Resources That Helped Guide Me On This 6 part series journey
- Continuous Delivery: Reliable Software Releases Through Build, Test, and Deployment Automation (Addison-Wesley Signature) – Humble/Farley
- The Technical Debt Trap – Doc Martin
- Advanced Test Driven Development – Robert C. Martin
Thanks for reading and keep building awesome.
Until next time!
Ian B
P.S. You can also find me on Twitter: @ianaldo21
Ian Barry 