TDD - The Toilet-driven development
Warning: profanity ahead!
An opinion is like an asshole. Everyone has one. – A modern proverb
It feels a bit strange to write anything remotely related to my gastrointestinal tract on a blog (and I really hope no one is genuinely interested in such topics), but there’s something funny related to it that will serve as a base of this post: some of my best solutions to hard problems were concieved while I was in the loo. I shit you not (pun intended)!
I don’t know was it some kind of epiphany, or simply having some quiet time alone to think, but it worked many times, unintentionally. It happend so often that even a CEO of a certain company I was working for noticed it - once when we were discussing some really hard problem at the office (like we did many times before), he turned to me and, to my surprise, half-jokingly said: “why don’t you go into the loo and come back with a solution?”. For better or worse, this is a true story. (And no, this doesn’t mean I’m spending way too much time over there at work btw)
So you could say I have a methodology that worked for me on many occasions. It would be selfish to keep it to myself, wouldn’t it? If it works for me, it must work for everyone else, amirite? Time for enlightening the world, earn some big $$$!
Perhaps I should talk about it on some developer conferences. Or, launch a podcast where I discuss the benefits of toilet time for software development. Maybe even write a book, rebrand TDD into Toilet-driven development. And if my methodology doesn’t work for some people, me and my faithful followers could use the opportunity to shout at them on how they can’t (do) shit properly.
But, why stop there? I could also invent shitting in pairs, or even mob shitting. The more the merrier, right? The solutions would just keep dropping out at an incredible rate!
What, you can’t share the same toilet seat with someone? Oh, such an introvert! You must work on your social skills, learn to think outside the box. Shitting in a toilet is a social activity now!
Now, I hope it’s obvious I’m exagerating things quite a bit here, but the analogy should be clear. In a nutshell, this is how selling of any particular software development methodology looks to me. Some things work under certain conditions, and with a certain group of people. It’s called a context. And anyone with a direct or indirect financial interest into success of a certain methodology will deny the existence of a context, because it would reduce their target area tremendously. And they don’t care if the ideas range from wrong to utterly deranged, the perception of those with the money is all what matters.
So, what would be the right methodology to use then? The cold truth is - none. It’s a roll your own methodology. If you want trully to be agile, you’ll think about your goals, the people that are working with you, and then mix and match what’s already out there along with a dose of common sense. But more on that later.
Obviously, all of this is my opinion on the matter. You can agree with me or not. These were not formed over a single day, but I understand that I may not have enough credibility to be taken more than lightly. But, you should also check how credible are the so called “authorities”. You’d be surprised.