Discussion: Leaner Tools To Better Prepare Undergrads?

Posted by Mike Bria on Jun 03, 2008

Sections

Process & Practices,

Architecture & Design

Topics

University Programs ,

Agile ,

Delivering Quality

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.

1. Back to top

   Wait a sec...

   by Bruce Rennie

   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.

   Reply

2. Back to top

   Sounds like you've just described vi or Emacs...

   by Garrick West

   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";)

   Reply

• Older >