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.
When I was in college, there were some guys I hung out with who played this game called “Questions” which they got from some book. Actually, it was a play.
Anyhow, the basic rules are:
You can’t answer a question with a statement
You can’t hesitate or make a false start
You can’t repeat a question that has already been used
You can’t ask a rhetorical question
You can’t ask an unrelated question.
There was also this podcast at DotNetRocks where they were talking about a beer app and how they had added game elements to the app by adding badges for various types of beer to get you out of your comfort zone. Maybe there is one for “My first beer that I liked” because I’ve yet to find something I like. But give me a good Merlot!
All of this got me to thinking about how we might turn Test Driven Development into something of a game.