While reading about TDD, and googling for Steve Freeman’s blog, I came across this post: “Say Goodbye, I won’t be Back”
It is about the Agile movement. The author said,
“People over process” can - and often should - mean: not doing an agile transition at all. Human beings have a right to choose which changes they want to go through and when. There are many valid personal reasons for not doing TDD, not taking accountability and not moving into a common team room. Let’s accept those reasons without being contemptuous and without trying to manipulate.
That hurts!
Too bad… because I have this plan of writing a post with the title “How to save ourselves from the wrath of future programmers”, where I will be dogmatically(?) suggesting the use of TDD.
But… the author has a point…
Should we force a team to do TDD when they are not yet familiar with it? — When they are not yet confident about using it?
Of course not! I believe that that will cause a disaster — a hatred for TDD; a hatred towards those who promote TDD.
Very bad. TDD is supposed to be fun!
Should we force someone to pair program when he is not comfortable doing it?
Of course not.
But, I think, the forcing thing is not necessary. We can try to say, “our masters discovered some things that helped them do their work better; should we try to do these things and see if they will also work for us?”
I think this matches with what Woody Zuill, my new a-hero, believes: “The people doing the work can best determine how to do that work”
These good practices discovered by our masters might not always work for everyone everytime everywhere. — So, lest I become dogmatic on using TDD (and the other great software development practices that our masters are promoting), and be hated by many for doing so , I’m going to post here some statements I recently read and heard, which, I hope, will serve as reminders for my future self not to be dogmatic on things I should not be dogmatic of.
Steve Freeman in an interview:
Q: Are there situations in which you consider TDD not to be the right approach for developing software? If so, what other techniques and approaches would you recommend in those situations?
A: …There are some kinds of “algorithmic” system (P-Systems) that should be addressed by thinking hard – although I’d still think that TDD can contribute to the implementation. I mostly work on “messy” E-Systems that evolve with their environments and don’t have clean requirements. This is where I think TDD, in its larger sense, is particularly appropriate.
Other possible exceptions are where something has to be thrown together to prove a point or where the programmer is exploring a space…
Robert Martin in the Q&A part of his talk on “Expecting Professionalism” starting at time 1:23:38
Q: If TDD is the answer to everything then why aren’t students learning it at school?
A: TDD is not the answer to everything. But it is a very good discipline…
Woody Zuill at the beginning of one of his talks on “Mob Programming”:
… I want to make it real clear. I’m talking about something that a team that I worked with experiences.
“The value of another’s experience is to give us hope, not to tell us how or whether to proceed.” - Peter Block
I’m not telling you how to do something or whether you should do it. I’m sharing with you how we did something and how it worked for us. And if you think you’re going to do it — what you will learn today — great! And I’d love to hear back from you, your experiences, because I’m going to learn from that.
But to tap myself in the back, I think I am not that prone to being very dogmatic on the use of these software development practices or disciplines… because I remember having this statement in my resume a while back:
I believe in “discarding practices that does not work in a particular team and retaining those that work”.
I am also influenced by Greg Howlett with this rule/philosophy in music: “if it sounds good, it is good”, (even if it doesn’t follow the rules musicians know or teach).
Also, I am influenced with the idea of Christian liberty, which says something like “there are things that are not clear in the Bible — we should not be dogmatic about them”. [1] Christians might be dogmatic on many things, most especially on the existence of the Biblical God , but Christians also know that there are many things that we might know for sure in this life. [2]
And… Oh… Maybe you will agree with me that this very post is evidence that I am not that dogmatic!
But I’m still going to write that post… (not in a dogmatic kind of way of course) Maybe?? I’m not sure. Maybe next year — when I already have more experience on TDD.
I still believe that TDD can save us from lots of troubles. But being dogmatic about it might bring more troubles; more resistance…
Footnotes:
[1] At this moment, I am more inclined to support those who limit than those who permit such liberties, because I grew up in a conservative kind of Christian home.
[2] One example of something Christians might not know for sure in this life is the answer to the question “why does evil exists?” But if we plan to reject Christianity only because it cannot have a sure answer to the question of evil, we first have to ask these kinds of questions: What is evil? Is murder evil? Why is murder evil? Is it possible for murder not to be evil in the future? Is murder viewed as evil in the Christian worldview?