Looks like I'll be in Michigan in early April, giving a talk or two at MSU. They'll be science talks, but at least one talk could be of interest to people likely to be reading this blog. Drop me a line if you're interested in coming.
It's not about the tools, dummy.
As you may know, I'm a fairly recent convert to "agile testing". Not XP or test-driven development, per se; for me, "agile testing" just connotes applying many small tests to all levels of your app to test it holistically, combined with automated continuous integration to make sure that stuff stays working. I'm into "agile development", too, although more by accident than by design. I've been a huge fan of rapid prototyping since the first year I started programming -- I was producing crappy but functional TCP/IP code within 3 mo of access to a UNIX system, back in 1990. I've also been using revision control since then, too: I started with RCS, learned to use CVS in the late nineties, and now split my time between Subversion and Darcs. This is how I work, nowadays: I write some code, get it working, test it at some or many levels, write some more tests, check it in, repeat.
From reading these two articles -- Livschitz and the Nightmare article -- I conclude that many people do not develop the way I do. Moreover, people seem to be focusing on tools -- language features and revision control tools, in this case -- rather than on process. I don't understand why.
What am I missing? Do people truly, really believe that the computer is ever going to do a better job of ascertaining or interpreting their intentions than they themselves are doing? It seems like this is what the fans of static typing, new & better revision control systems, and UML all believe. I just don't grok how specifying behavior in ever more ontologically controlled ways is going to get you past the central social issues of software engineering, which lie in first figuring out what your software should do, and then communicating those intentions to other developers. These are social, not technological, issues, and they cannot be solved technologically. We can be aided by specific tools - personally, I find that using a fairly high level interpreted language helps with many of my problems -- but I was rapid prototyping in C long before I found out about Tcl, Perl, and Python. I struggled with RCS revision control in the early '90s, but I never thought that the reason I was developing bad software was that I had to lock individual files and manually merge contributions. I wrote tests before I had unit test frameworks. But I never confused the technological limitations of my tools with my failures of process, and I never stopped trying to learn better processes.
It is perplexing to me that such simple statements as "write code that incrementally approaches your goals" and "make your best effort to test that code" -- the two cornerstones of Agile Development and Agile Testing -- are apparently so difficult to comprehend or effect for so many people.
My best guess (and this is where my lack of experience may handicap me) is that people like Livschitz are trying to solve communication problems inherent in large team projects. It is necessary to work with multiple people to accomplish big things, and that's scarily difficult -- big game development scares the willikins out of me for that reason -- and I can imagine projects where it's impossible for any one person to grasp more than the basic elements of the overall design. It may well be that people are trying to substitute for proper testing with static typing and interface enforcement, and the purpose may be to use these tools to communicate between developers and teams across time and space. If this is the case, then I think they're being foolish. Unit, functional, and acceptance tests work just fine for communication at all levels of your application.
This general problem may be what Jon Udell is pointing out in his argument against standards, too. Don't try to communicate outside the code: make the functioning code itself your exemplar.
P.S. I am in no way blaming the Nightmare author for his problems. (It's clear he's never actually used subversion, which lets you solve merge issues in your own repository prior to check-in.) I am questioning the way his company develops, however.