“After having devoted a considerable number of years of my scientific life to clarifying the programmer’s task, with the aim of making it intellectually better manageable, I found this effort at clarification to my amazement (and annoyance) repeatedly rewarded by the accusation that “I had made programming difficult”. But the difficulty has always been there, and only by making it visible can we hope to become able to design programs with a high confidence level, rather that “smearing code”, i.e., producing texts with the status of hardly supported conjectures that wait to be killed by the first counterexample.”
— Edsger W. Dijkstra “A discipline of programming”
I struggle to never write comments that can be drilled down to “Great stuff, dude. Write more on the topic!” Instead I prefer keeping silence if I have nothing to add or ask but nitpicking. In part, because I do not want to look as one “leaving inane comments on blog postings written by people who care about the craft”. Better to remain silent and appear a fool than to open your mouth and remove all doubt.
This time I gonna make an exception though. As you could notice, Michael Bolton had posted a beautiful argument against using passed vs. failed ratios “as a means of estimating the state of a development project”. You can easily imagine how popular such metric is. My team, for one, used it until our latest project. We weren’t happy with it. It took us quite an effort, certain dose of persistence, and a fair amount of guerilla tactics to quit this metric. If you ever walked the similar path, you can easily imagine how thorny it is. (“Trying to solve the problem on your own seems the only way in which you can assess how difficult the problem is”, yeah?)
Part of the problem, of course, was that we didn’t have our arguments worded as beautifully as Michael did in the post. Thus, one can expect that publication of Michael’s work inevitably makes life for all other practitioners more simple. There’s another factor. As a rule, ideas expressed by renowned thought leaders have more influence on managers than the very same ideas expressed by managers’ peers. I’m OK with that. This again increases importance of Michael’s contribution.
I hope, at this point you can understand why I was shocked by Adi’s comment that he (she?) got “tired reading more and more test articles that fall in the philosophical side”. Please, don’t get me wrong. I’m not an enemy of good case-studies and real-life examples. I do know that “all experts… operate on the basis of intimate knowledge of several thousand concrete cases in their areas of expertise.” I’m a big fan of war stories, after all. But dismissing something on the basis it is “philosophical”, seems strange to me. What shall we do then with ontology and epistemology? Never spell their names?
My formal education was some hybrid of mathematician and physicist. Philosophy course was mandatory part of the curriculum. I remember that everyone expected it to be dull waste. Prior school experience suggested such expectations. Believe it or not, but philosophy was the funniest course I took that year. Believe it or not, it is philosophy course that I find the most useful for my tester-self.
I wonder, do most people fail to accept that software testing is social science (note both “science” and “social”) or just do not bother to even think about it? It is year 2012, how can it look like most people didn’t even hear about qualitative research?
PS. And yes… Great stuff, Michael. Please, write more on the topic! I take my hat off before you and all the other testers advancing our craft.