This post originated from an RSS feed registered with Agile Buzz by Keith Ray. Original Post: Tweaking Stuff Until It Works Feed Title: MemoRanda Feed URL: http://homepage.mac.com/1/homepage404ErrorPage.html Feed Description: Keith Ray's notes to be remembered on agile software development, project management, oo programming, and other topics. Latest Agile Buzz Posts Latest Agile Buzz Posts by Keith Ray Latest Posts From MemoRanda

A comment by Adrian Howard on Ralph Johnson's blog:

I've found TDD especially effective with new programmers. They no longer make that classic beginners mistake of typing a bunch of code then tweaking stuff at random until it works. TDD forces them to move in small increments and they get continual positive feedback - absolutely fantastic for learning.

Unfortunately I've seen "experienced" (non-XP) programmers who work the same way - typing a bunch of code then tweaking stuff at random until it works. Even worse, whole projects where the tweaking is done in the "testing phase". Those kinds of projects tend use a process I call "unconscious waterfall": there's a coding phase, and a testing-and-fixing phase, (and very rarely a design phase at the beginning). The testing-and-fixing phase tends to take the longest amount of time. See also CodeAndFix.

Those unconscious waterfall projects tend to give responsibility for "quality" to the testing staff, when the true responsibility for testers is to report on the state of the project. Writing quality code is ultimately the developer's responsibility, and there are many tools to help: TDD or unit testing, pair programming or code reviews, etc. QA's role is to provide some feedback, but it usually comes too late in unconscious waterfall projects.

Check out a paper by Joahanna Rothman for testers on non-agile projects: What do they pay you to do? and this one on testing in an agile project: Testers Shine on Agile Projects. What a difference!