InfoQ

News

Discussion: Leaner Tools To Better Prepare Undergrads?

Posted by Mike Bria on Jun 03, 2008 08:06 AM

Community
Agile
Topics
Delivering Quality ,
University Programs
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.

Related Sponsor

VersionOne is recognized by Agile practitioners as the leader in Agile project management tools. Companies such as Adobe, BBC, CNN, Dow, HP, IBM, Sony and 3M have turned to VersionOne to help deliver greater value to their customers.
Wait a sec... by Bruce Rennie Posted Jun 4, 2008 10:44 AM
Sounds like you've just described vi or Emacs... by Garrick West Posted Jun 4, 2008 4:44 PM
  1. Back to top

    Wait a sec...

    Jun 4, 2008 10:44 AM 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.

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

Educational Content

Bindings, Platforms, and Innovation

This presentation focuses on the Internet and separating myth from fact, history from the future, and the mundane from the imaginative. Bob Frankston presents a vision of what could and should be.

Orchestrating Long Running Activities with JBoss / JBPM

This article explores the use of JBoss and jBPM to implement design solutions that effectively address the issue of orchestrating long running activities.

Neo4j - The Benefits of Graph Databases

This presentation covers the use of graph databases as an optimal solution for data that is difficult to fit in static tables, rapidly evolving data or data that has a lot of optional attributes.

Realistic about Risk: Software development with Real Options

This session introduces Real Options and shows how it can help in running your project. Real Options is a decision-making process that can be used to manage risk.

Communication Flexibility Using Bindings

This article discusses the use of bindings on services and references (including the instance of non-configured bindings) as the means to implement SCA communications in a Web and SOA environment.

Writing DSLs in Groovy

After a short introduction to DSLs, Scott Davis plays with the keyboard showing how to approach the creation of a DSL by typing working snippets of Groovy code that get executed.

Scaling Agile with C/ALM (Collaborative Application Lifecycle Management)

IBM Rational and InfoQ present, Scaling Agile with C/ALM, an eBook showing organizations how to become “finely tuned software delivery machines” by enabling team integration and scaling.

Concurrent Programming with Microsoft F#

Amanda Laucher presents a real life enterprise application written in F#. She shows actual code snippets, explaining design decisions and suggesting how to use some of the F# constructs.