While I’m not entirely on board with throwing out TDD, the one thing I will agree to is that learning TDD is difficult. I am also willing to admit that, to a large extent, TDD is broken. If you’ve been following my post for a while, this SHOULD be shocking news.
And so, I’ve been thinking. Maybe we’ve been asking the wrong question. Maybe, instead of asking “How do we encourage people to implement TDD?” We should be asking, “How do we make TDD either unnecessary, or trivial to implement?”
There have been a number of things that have occurred over the last week that have prompted this particular post. And for anyone I work with, this is not an indictment of our work place so much as it is an indictment of our industry. PLEASE don’t take this personally.
Some of those reasons will show up in this article. But the question we need to examine today is why is it so hard to write bug free code. And I’m not even talking about perfection. Why is it that we miss the simple stuff? The stuff that once it is found, we think, “how could we have missed that?!”. I’m perfectly aware that all code has bugs some just haven’t been found yet. I’m also aware that no matter how hard I try, the stupid bugs always make their way past my desk.
I’ve written about Agile and Scrum before and most of my regular readers know that I am a huge fan. But recently I am starting to believe the Agile movement is doomed. In fact, the most common response to my enthusiasm for Agile and Scrum is, “Yeah, we tried that once and it was a complete failure.” Which seems odd to me because in every instance where I’ve been able to implement it, it has worked beautifully. So why would I say Agile Will Not Succeed?
The buzz around Agile has become so loud that Agile has moved from strictly a software development thing, to all corners of the business world. And yet, as much as I believe Agile is the right way to develop software, as a movement, it is doomed for failure. Why?
When I first wrote down the idea for this post, I was originally thinking about how we might use agile development practices in a work place that practices Water Fall or worse. But since then, I’ve expanded my thinking to include the concept of using agile everywhere, including where it “isn’t allowed.”
Here’s what I’m talking about. What does your work environment look like? Many of the places I end up working either are using no formal process at all, or weakly attempt some form of Scrum or Water Fall. In fact, my current major gig has a “project manager” (I use the term loosely) that manages our project with MS Project. There is not even a formal issue tracking system. And this is at a very LARGE organization that SHOULD know better.