A long time ago, in a place just a few miles from here, a young boy was given a TI 99/4A computer and a stack of BASIC programming magazines, and thus began a lifelong journey…
The TI computer sparked my hobbyist phase, which eventually carried me through the Apple and Commodore families before settling on the IBM PC platform in high school. In college, I further refined my passion, studying industrial robotics, electronics, and x86 assembly language.
After a few years’ hiatus to pursue some non-technical adventures, my professional software engineering career began in 1999 when I won a contract to write a custom interface between a specialized piece of hardware and a hotel’s property management system, and I never looked back. Over the years I’ve worked with a wide range of teams on a variety of projects with varying degrees of success, and I’ve noticed a definite correlation between TDD and likelihood of project success.
Although I was originally introduced to TDD in 2005, I didn’t really see its true value until 2012 when our team was acquired and moved under a manager who was not only deeply committed to TDD, but also exceptionally knowledgeable about the wider scope of practices that support (and in certain cases even enable) TDD. Within 6 months, our team underwent a complete transformation, refining our practices, refactoring code, and updating our existing “unit” (actually integration) tests to be actual unit tests. There were definitely pain points – we faced technical challenges, occasional team challenges (i.e. buy-in), and challenges communicating about TDD with management who viewed it as an unnecessary time sink. In the end, the team stood its ground and built a solid, reliable, successful product.
I started TddGuy.com to share stories of my experiences and hopefully spark community dialogue and knowledge sharing about this valuable practice.