Meeting commitments vs. testing and refactoring: false dichotomy
In the March 1, 2009 issue of SD Times, columnist Andrew Binstock states, “It is easy to endlessly test and endlessly refine and refactor code to the point that it becomes an all-consuming diversion that does not advance the project. And leading agile exponents–Kent Beck, Bob Martin (especially) and others–tirelessly support this.” Mr. Binstock is wrong.
Removing the inflammatory emotional words from the above, I get: “Kent Beck [Bob can answer for himself] supports testing and refactoring in ways that don’t advance the project.” What?
Maintaining strong relationships maximizes project value. A big part of maintaining relationships is making and meeting commitments. In the short term, if I encounter a tradeoff between delivering as promised and writing a test with small value or performing a refactoring, I deliver. (This is different than knowing the software isn’t ready and pretending to deliver anyway, which I don’t recommend.)
However, if I don’t write tests and I don’t refactor when I know these activites would add value, I harm my ability to make and meet commitments in the future. Sometimes I take too much on my plate for today. Fine, I deliver anyway even without all the tests I’d like or without clean code. But then I adjust–slow my commitments until I can make up the deficit and put myself in a better position to deliver in the future.
If Mr. Binstock would like to explain why this is bad policy, I’m all ears.
I understand Mr. Binstock’s concerns. What I don’t understand is why he and people like him and Joel Spowlsky insist on attacking things they do not grok and people they do not really know.
Anyone who has not read Refactoring and TDD (Fowler, Beck respectively) does not grok TDD or refactoring.
Anyone who has read either, or preferably both, understands that Mr. Beck does not support the views Mr. Binstock claims he does.
Sheesh, when people like Kent Beck and Robert Martin put forth so much effort to make software development a better place to make a living and make it a fun thing to do, then they deserve enough respect that when one chooses to criticize them or their work, and least obtain a cursory understanding of them or their work first.
Curtis,
I understand the possibility that people could endlessly futz with code without contributing to the project. I’ve been guilty of this myself, particularly when I am feeling terrified of feedback about the functionality of the code. What I don’t understand is why I am perceived as “tirelessly supporting” this. That’s what I’m hoping to have explained out of all this.
I think the problem with most of this is that the benefits are unintuitive. The first time I heard about automated testing, these were the problems that came to mind:
1) Yeah, but now you’ve gotta write 2x the code: The tests and the features.
2) Yeah, but once they’re in place, now you’ve gotta change the code in two places to add a feature.
3) Yeah, but who tests the tests? Not only are you writing twice the code (#1), but you’ve got more places that bugs can hide.
4) Since I can’t _guarantee_ bug-free code with tests, it’s really a waste of time because QA will have to be just as thorough with or without them.
IMHO, automated tests don’t make much sense until you _try them_ yourself and get some decent code coverage first. If you merely _think_ about the pros and cons, you’ll come to the conclusions I listed above.
There’s no preview feature on this blog. I’m crossing my fingers that this gets formatted correctly
It would appear that Mr. Binstock is not particularly interested in explaining himself. But don’t worry, Kent, he has absolved you from all wrongdoing with the words: “If I were to change [my article] at all, it would only be to remove the reference to Kent Beck.” (See: http://tinyurl.com/crordb)
I, on the other hand, remain an unrepentant zealot who endlessly gilds his lily. <grin>
Kent,
I don’t know why you are accused of it either. Nothing I have ever read that you have written nor anything I’ve ever heard you say gave me the impression that you tirelessly support needless refactoring.
Great that you are taking the effort to “set the record straight”. Recently, it feels like there are a few attention seeking individuals who are moving their mouth without any logical basis for the sake of attention. Like every industry, even we have our “Paris Hilton” and “Britney Spears”. It’s quite embarrassing and unfortunately also dangerous. The garbage they spew out tends to create quite a shockwave of stupidity that lowers the collective intelligence.
Is there anyway we can nullify their effects without wasting our time by responding? Unfortunately, I don’t think so. I commend your efforts in fighting the good fight. Keep it up for there are many of us who are cheering you on.
>>>> This is different than knowing the software isn’t ready and pretending to deliver anyway
How would you know “the software isn’t ready” without tests?
I typically have a list of tests that I haven’t written yet but that I suspect will fail. If one of those is inside the realm of what customers can reasonably expect to work, I know the software isn’t ready even though I don’t have a concrete test. It’s better if I have the failing test, because then I’m sure. OTOH, by the time I have the failing test I generally have a pretty good idea how to make it pass.