So now we come to the true confessions part of the story…
The fact is, with the exception of the firing part (I plead dramatic license), both scenarios are from my actual career. In fact, I personally experienced both sides of this story about a year apart, at different stages of the same project, with largely the same development team. My point is that our team wasn’t magically gifted one day with secret knowledge of TDD, code quality, or related concepts – instead it was a steady process of continuous improvement, actively learning and applying new concepts while refining our practices. At times it was challenging and painful, but our ensuing successes clearly show the value we gained by adopting and adhering to this process. My goal with this blog is to share my software engineering experiences and lessons learned with the community at large, focused primarily on TDD, code quality, and engineering best practices, while fostering community discussion on these topics.
Because TDD and code quality don’t exist in isolation from one another, I’ll probably be covering a range of seemingly-unrelated topics. My hope is that gradually these parts will coalesce into an overall picture providing guidance along with an understanding of where all the pieces fit. The ultimate goal is to provide a resource outlining ways to:
- Ensure software robustness
- Minimize risk of change
- Improve code testability
- Improve software architecture
- Understand and apply TDD principles
- Use TDD tools to automate integration, acceptance, and regression testing
It may be a long and interesting ride, but that’s what adventures are all about!
Leave a Reply