August 1, 2012

Software engineers have an uncommonly difficult job. Not only are they tasked with the monumental challenge of accurately modeling a business in digital interactions, they also need to be constantly permuting the different ways they could be solving their problems and the pros and cons of each possible implementations. To make matters more difficult, they’re having to constantly juggle the ever-evolving needs of the client and an employer who thinks having something done yesterday is still late. You’d think that with all of this, we’d find little time to resist the progressive development philosophies and methodologies that have proven themselves for years from entrenching themselves in our day to day lives.

Not too long ago I was with a new colleague that I’ve come to amass a significant amount of respect for. In the presence of other fellow trusted technologists, we heard something rather alarming – their team had made the conscious decision to not practice test-driven development. “Certainly there must be more to this,” we thought, and proceeded to probe a bit. It became quickly apparent that there was no deeper truth to discover — the team was comprised of engineers who had intentionally opted out of TDD in order to code faster. This was extremely disheartening to both of us, and after a moment of disbelief and frustration, my colleague exclaimed “I thought we had polio beaten!”

Why in the hell are we still arguing about this? We have bigger fish to fry. I understand if you’ve never done TDD and as such are hesitant about your short-term throughput. Spoiler alert: it’s not going to be great, especially if you don’t have someone on your team who has strong experience with it. But that doesn’t change the fact that opting out of it really shouldn’t be an option. This comes down to professionalism, and with all the commotion of rapidly changing requirements juxtaposed against building quality in at the ground level, there’s little time to be resistant to the progressive methodologies (from the past) that have finally started taking root. It’s time for some solidarity among engineers – we have tough jobs, let’s not make it tougher on each other by fighting against things like TDD.


John is a serial conversationalist who spends entirely too much time engulfed in problem domains he knows nothing about and has no earthly business trying to learn. He can occasionally be found at your local coffee shop writing algorithms and trying to think deep thoughts.