It is possible to write software that solves real business problems, cheaply and reliably. The recipe is well known, even though it's not easy to do.
I am a software developer. I'm happy to work as a programmer for ThoughtWorks, mostly in the Milano area. I teach at the Università dell'Insubria.
Working with me: if you're a computing student, you may do an internship with one of my (former) clients. If you are a developer interested in working in a team that does Extreme Programming, send me your CV.
here is the post: http://parlezuml.com/blog/?postid=987
Thinking some more about this, I think the line that really bothers me is "we move on to the next easiest failing test."
Maybe it's a poor choice of words but, taken at face value, I think it illustrates a deep misunderstanding of TDD.
Firstly, TDD is not about writing a bunch of failing tests that we make pass one at a time. TDD stipulates that we write one test at a time, implement just enough to make it pass, make the implementation as simple as possible (note: simple, not easy), and continue by writing another test.
Secondly. we don't order tests by what is easy. We test what we need to do next and we MAKE that easy to test. Making it easy to test might actually be difficult to do: it might bring to light a shortcoming in our design and force us to address it.
That, to me, is the essence of the TDD process: the experience of writing a test gives us feedback about the quality of our design. And I want that that feedback is to be met head on, not avoided by always taking the easy route.Nat Pryce, on the GOOS mailing list