Friday, February 10, 2006
The Simplest Things Can Possibly Fail
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.
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.
