Jonathan Kohl and I were chatting recently as we often do. (Chatting with Jonathan is so interesting and enjoyable and productive that it sometimes has a serious impact on other forms of productivity.)
We’re observing together the evolution of agile development, in terms of what I’m proposing to call “mythodology“. (I invented this term independently, and was sorry to see via a Google search that I wasn’t the first person in the world to use it. However, I’d like to go down in history as the person who coined the term with respect to software development; please feel free to help me in my goal. But I digress.)
Most recently, Jonathan was bemoaning what he observes to be an excess of YAGNI (You Ain’t Gonna Need It) and STTCPW (the Simplest Thing That Could Possibly Work), two allegedly essential agile principles. Specifically, he was observing what he considered to be (and which testing demonstrated to be) sloppy work, and the rationale that was being presented for it was that it was STTCPW. Recall that, as James Bach says, “when a developer says ‘it works’, he really means, ‘it appears to meet some requirement to some degree.'” STTCPW becomes toxic when “it works” fails to include some pretty fundamental requirements–for example, releasing a resource that you’re finished with. STTCPW might NRW (Not Really Work); applied thoughtlessly, it can slip into OLLIW (Only Looks Like It Works).
As with any mythodology, principles that begin with reasonable grouding can be misapplied and corrupted. This reminded me of James’ observation that the Traditionalists and the Agilists are both instances of the Routine or Factory School of Software Testing (as Bret Pettichord describes in his wonderful paper Four Schools of Software Testing). I may disagree with James to the degree that I don’t think the early or smarter Agilists intended to behave in a Routine-School manner, but I think he’s right to point out that a large and growing number of their disciples appear to have slipped into Routine behaviour. The common element between Bad Traditionalist processes and Bad Agile Processes is that both want to remove that irritating thinking part.
In my experience, I’ve known process-followers and I’ve known experts. The distinction between them is that the experts can follow processes, but they don’t follow them blindly. Instead, they incorporate critical thinking–and in particular self-critical thinking—into everything that they do. The experts demonstrate humility perfectly balanced with arrogance, and confidence with fallibility. They tend to pause and think for an extra moment before deciding that they’re done. Rather than simply assuming that YAGNI, they consider the possibility that you might really need it, or that STTCPW might be too simple and might not work. Agility in the face of excess bureaucracy is welcome, but it’s strengthened when it’s tempered with reflection.
Ah, yes–Sloppy work under the guise of the Simplest Thing That Could Possibly Work. I’ve seen that, and it results from the same misapprehension about what STTCPW means as that presented here.
First, it’s not one of the XP Principles (which I have listed at Xp Principles), though it related to Assume Simplicity, and perhaps to Small Initial Investment and Concrete Experiments.
Second, the point of the Simplest Thing exhortation is to avoid over-engineering things up front. The term Simplest is not related to Easiest, in this context. It’s not about avoiding boundary cases. It’s not about neglecting resource management. It is about thinking–thinking about what your requirements are today rather than what they might be in the future.
Michael, I think you have fallen for the same myths you deplore. This article would mostly be railing at a strawman, were it not for one brilliant sentence. “The common element between Bad Traditionalist processes and Bad Agile Processes is that both want to remove that irritating thinking part.” That truly is the failing in so many endeavors that go wrong.
Hi, George…
Thanks for the comment.
Note that I didn’t claim that STTCPW is an XP principle. Nor did I claim that STTCPW was anything good or bad, but rather that STTCPW was being presented by some as an excuse for sloppy work. My complaint is not with STsTCPW; I tend to like STsTCPW. My complaint is with the idea being co-opted by the sloppy or the lazy, thus bringing a good idea into disrepute by association. So I would respectfully dispute the idea that I’ve fallen for myths; I’m just disappointed and angered by those who are giving good ideas a bad name. I don’t think they’re straw men; they do exist, and I think they should be criticized fearlessly.
By the way, I’m at Agile 2006 as I write this, and I’m greatly encouraged by the spirit of many of the people I’ve met here. I hasten to note that they’re not the ones I’m talking about in this posting.
[…] prevent any discussion (and loss of potential paying clients). Examples are here, here, here, here, here, here and here, just to name a […]
This one’s hilarious. All abut one of the studies that Mario cites have the same author (Juha Itkonen) and the same problem: in the analysis of the efficiency of scripted testing, they neglect the time required to prepare the scripts—and they neglect the fact that preparing test scripts is itself an exploratory process. The last paper is a real knee-slapper; it suggests that exploratory testing is a cause of technical debt(!); that exploratory testing is bad because it might be done by unskilled people; that exploratory testing is entirely undocumented and unsystematic; the usual litany of misconceptions and ignorance. It would be tough to take any valid conclusion from this paper. I suppose one reasonable albeit non-newsworthy idea is that bad exploratory testing—like bad academic research—is bad.