Discussion: Leaner Tools To Better Prepare Undergrads?

Greg Wilson recently challenged the "Agile Automated Functional Testing Tools" community to support his efforts to improve new college graduates ability to deliver "product-quality code".  Wilson's proposed means of doing so primarily involves providing simplified versions of the tools used by professionals, such that they're digestible by the average undergraduate computer science student.

I'm now convinced that if we want things to change, we have to think about scaling down our tools and techniques to fit novices' heads. In particular, any tool that can't be learned in a one-hour tutorial, or that doesn't pay its way in the first assignment it's used on, [is likely to be tossed aside and largely ignored by most students].

Wilson concludes his initial post with his thoughts on requirements for a tool to be suitable for students:

• Must be comprehensible to a second-year Computer Science major who's running a C+ average after a one-hour tutorial.
• Must make students who are time-slicing assignments from four or five courses more productive within one month of adoption (i.e., after five to ten hours of use spread over two weeks).
• Must be platform-neutral (some courses uses Java, others use Python or C, and of course there's the Windows/Linux/Mac issue).
• Must be useful in courses other than the one where it's taught (i.e., databases, compilers, graphics, etc.). This is actually our measure of success: after introducing version control in second year, we see a lot of students setting it up and using it in third- and fourth-year courses without being told to.
• Must be (relatively) process neutral: I believe a good solution would be as usable in RUP as in XP (just as version control and unit testing are).

The early responses consist of an interesting, but somewhat tangent, conversation triggered by Ward Cunningham, expert in (among others) the XP and Automated Testing Tools communities.  In it Ward poses a polite but pointed challenge to Wilson's apparent motive:

I'm not sure product-quality code should be the goal of an undergraduate education.
...
[As an undergraduate student,] I was on to two streams of knowledge: lots of big organizing ideas from my professors, and lots of handy technique from my own exploration. There was still a third stream, product-quality, that I had yet to tap.

In essence, while it appears Ward does not oppose Wilson's efforts to improve student's ability to come out of school with a more solid grasp of the tools and technique's used by professional Agile practitioners, he sees this not necessarily as a great contributor to improving student's appreciation for "product-quality software". To gain that, Ward asserts, takes experience with real products.

Much of the thread following this includes interesting discussions about commonly used tool's applicability (or lack thereof) considering Wilson's constraints.  Among those discussed are FitNesse, Selenium, Watir, Concordian, and a new ThoughtWorks "collaborative testing" tool called Twist.

Take a moment to check out the AA-FTT yahoo thread for more info on what conclusions the group came to.