Skip to main content

Tools That Do Too Much?

Posted by gsporar on February 22, 2007 at 1:35 PM PST

Kathy Sierra recently posted an interesting
blog entry that asks: Are our
tools making us dumber? This debate rages in the IDE world all the time,
especially amongst folks who teach.

Last year when Geertjan and I were doing
presentations
for the folks who are certified to teach Sun's Java
training courses
we frequently heard complaints about how the use of the
NetBeans IDE in the lab exercises
would result in students who do not know
how the technology really works. For what it's worth, I don't think that
always has to be the outcome - and there are several of the instructors who
agree (for an interview with one, see this).

I don't deny for a moment the idea that if you get hooked on just using a particular
tool and ignore the fundamentals then you can eventually end up in dire
straits. But there are several ways to avoid this problem - the first being
one mentioned in that blog entry: start doing your learning without a
tool. And in fact that is the technique used in Sun's Java courses - the IDE
is only used in the labs. The classroom instruction is where the technology
is taught. Properly used, a good IDE is a productivity tool, not a crutch.

Beyond that, Ms. Sierra suggests to tool makers: "If you make a tool that's
hiding things the user should understand, maybe you could provide a tutorial
or even an understanding mode where the user can ask the tool exactly what
it's doing and how it made the decisions it made." Seems like an
"understanding mode" might be difficult to implement in the automatic
transmission of a car. :-) But with Java IDEs these things are a bit more
achieveable.

There are several features in the NetBeans IDE that I think help prevent
people from becoming so dependent on it that they do not know what is really
going on. Some of them are listed below.

  1. Transparency. The default project system for the NetBeans IDE is based on Ant. All
    project information is kept in plain-text files. So there are no proprietary
    binary formats to worry about.
  2. A physical view of the project. IDEs like to display a logical "project view"
    of your stuff and the NetBeans IDE is no exception. This is nice and everything, but
    you need a physical view of exactly what is happening in the file
    system. So if you want to know exactly what sorts of files the IDE added
    with one of its wizards you can easily open the Files view.
  3. Integrated help for the tool and the technology. For example, if you open up the help file
    in the NetBeans IDE while using something like the nice editor it provides
    for a web.xml file, you get help on not only the IDE's editor features but also
    on what web.xml is all about, what it contains, etc.
  4. Tutorials that cover not only the tool, but also the technology.
  5. Diagnostic tools. As mentioned above, the project system is based on Ant.
    If things are not going well with the IDE generated build script, there is
    an Ant debugger included so that you can easily look around and see what is
    going on.