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.

The problem is that automated FUNCTIONAL level testing is not a clear "win" in all situations. It's not a slam dunk that this is the right thing to do on a project. And I say this as a veteran of many agile projects. Automated UNIT testing, yes. Automated functional testing, nope.

To me, testing is mostly about economics. Complete testing is usually economically unrealistic for most projects. Fortunately, it's also not usually necessary. Automated testing has a much larger up front cost than manual testing and you have to think carefully about your ability to see a return on investment in the long term before simply jumping in.

I would settle for undergrads being exposed to unit testing and testing techniques in general. Forget about automation, just teach new programmers how to test. Once that is learned moving to automation, if feasible, should be relatively easy.

Seriously. If the goal is to learn, then the best "lean" tool for the job is an editor with syntax highlighting for the language in question. Some of the macros and automation can be added on with the modern variations and adaptations (e.g. GVIM, XEmacs). As the Pragmatic Programmer guys suggest, pick an editor and learn it well. IDE's can be a crutch that removes you from the development process if handed to developers who are still trying to learn a language and platform. While they're great for developers who already have gone though the process of learning and understanding the language statically and at runtime, they tend to obscure too much of what's going on and some aspects of a language may end up being "that magic the IDE does for me".

Being 10 years out of school, I'd have to say: "Here's a nickel, kid. Go download yourself a free programming editor";)

Is your profile up-to-date? Please take a moment to review and update.

Email Address

Note: If updating/changing your email, a validation request will be sent

Company name:

Keep current company name

Update Company name to:

Company role:

Keep current company role

Update company role to:

Company size:

Keep current company Size

Update company size to:

Country/Zone:

Keep current country/zone

Update country/zone to:

State/Province/Region:

Keep current state/province/region

Update state/province/region to:

Subscribe to our newsletter?

Subscribe to our industry email notices?

You will be sent an email to validate the new email address. This pop-up will close itself in a few moments.

We notice you're using an ad blocker

We understand why you use ad blockers. However to keep InfoQ free we need your support. InfoQ will not provide your data to third parties without individual opt-in consent. We only work with advertisers relevant to our readers. Please consider whitelisting us.