Gregg Sporar's Blog

Tools That Do Too Much?

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.

Comments

• "Properly used, a good IDE is a productivity tool, not a crutch.
  "
  Yes, but during a language training course your productivity is NOT measured in the amount of code you turn out but the amount of knowledge you absorb. And using an IDE (especially one the students aren't yet familiar with) in such a course means they have to learn the tool as well as the language (and many will end up learning the tool instead of the language, just look at the forums where just about every other question is of the form of "do XXX with Netbeans doesn't work, hlp me plz asap", or else people who learned to program using an IDE and when encountering an environment without one are completely lose. I've seen people who have been programming Java for years yet are unable to set a classpath correctly for example. They're essentially useless without their IDE (some even break down when encountering a new version of that same IDE where the buttons are in a different location)).
  

  Posted by: jwenting on February 23, 2007 at 06:29 AM

• I start off teaching with cmd and notepad. That helps them to understand what an IDE is actually doing for them.

  Then I move to the free version of JCreator, which provides API lookups, syntax highlighting, and a convenient way to compile and run stuff, but not much more.

  I should probably move to NB, Eclipse or IDEA with them - but I don't have a lot of choice, NB is the only one installed in the labs I use. NB is also my least favourite, I'd still rather use cmd and Notepad than it because of some usability flaws. The only reason I'd move is for code completion - they use copy and paste far too much, which slows them down no end, distracting them. Yesterday I saw someone copy and paste 'id'. Thankfully, he knew it was stupid.

  Posted by: ricky_clarkson on February 23, 2007 at 06:48 AM

• "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."
  Plain-text or not, the IDE generated Ant scripts are about as easy to read as binary. Have you looked at the default (over 500 lines!) nbproject/build-impl.xml file created for a simple Java app? Thank goodness there is an Ant debugger! This has always been a complaint about IDE generated files. The complexity required to support everything you can do with the IDE dictates large, complicated autogenerated files. I could replace that default script with a simple build.xml of less than 50 lines! Granted it would be a lot less useful, but a new programmer learning Ant could figure out what it was doing in less than 30 minutes.

  Posted by: dcartwright on February 23, 2007 at 07:14 AM

• @jwenting: I would agree with the importance of the knowledge absorbed, instead of the amount of code turned out. My question for you would be: "What is the cause of the problems you list?" In other words, is the problem really the usage of a tool in a training class or is the problem the way in which that tool is used? For example, in Sun's entry-level Java training course for developers (SL-275) the IDE is basically used as a text editor that provides syntax highlighting and code completion. In later courses, for example on web development, there are various IDE wizards that are used to create things such as servlets. But note that the IDE is configurable so that if the instructor so desires, the amount of code generated by the IDE could be cut to zero.

  Posted by: gsporar on February 23, 2007 at 07:55 AM

• @ricky_clarkson: I'd be interested in hearing about the usability problems that you think make the NetBeans IDE a bad choice. You can always open IssueZilla entries at http://www.netbeans.org/community/issues.html or just leave more comments.

  Posted by: gsporar on February 23, 2007 at 07:57 AM

• @dcartwright: Yes, the default build-impl.xml file is large. But as you point out, that verbosity is "required to support everything you can do with the IDE." FWIW, you can always create projects with the NetBeans IDE where you use your own build.xml, instead of one created by the IDE.

  Posted by: gsporar on February 23, 2007 at 07:59 AM

• Thanks for adding so much to the discussion, Gregg -- you make some excellent points (and you got me on the whole automatic transmission thing ; )

  
  I am heavily biased, and you pushed a big button for me here -- back in the day when most of Sun's Java instructors were employees, I worked at Sun as both a Java course developer and later one of three master trainers responsible for training and certifying instructors on Sun's courses. When I heard that Sun was going to require NetBeans in their courses, I fought hard against it (to no effect) for a variety of reasons, many of which were brought up here by commenters. But my main problem was that it became obvious that [political rant here] Sun would not be able or willing to commit the resources to NetBeanify their courses in the best interest of the customer and the instructor.

  
  I may be dead wrong -- but even the folks responsible for pushing through this change in Sun's courses said that they were explicitly looking to use this as a means to increase NetBeans adoption. Their heart was kind of in the right place--"if new programmers see how much more productive they can be, they'll realize that this can be a better experience for them..." but they seemed to have inconsistent and unrealistically optimistic data about:

  
  * the ability of NetBeans (at that time) to support the kinds of work done in the courses--especially the EJB course

  * the popularity of NetBeans in the marketplace

  
  * the willingness of students to attempt to learn BOTH the IDE and Java (or whatever edition and API was being taught) simultaneously.

  
  Nobody I spoke with at Sun regarding this decision ever mentioned the additional cognitive load this would place on students. Not that there isn't a way to resolve that, but in my opinion the courses would have to be changed dramatically to support NetBeans, as opposed to simply modifing the lab files to do them in the IDE instead of by hand. You can't just retrofit an IDE into a course...

  
  I do agree with you that in SL275, this is less of an issue, although I still think it's the wrong thing to do for learners. But it's much more serious with higher-level courses. There is an EJB course where virtually none of the labs could be completed with NetBeans because of problems with the earlier version that went *against* the J2EE/EJB specs. (This *may* be fixed by now, but as of three months ago, all the labs in that course were still failing for most students).

  
  There were also multiple, fatal errors when student labs were NetBeanified for the Servlets and JSP courses as well. I spent an entire week a few month's ago watching a Sun servlets course where not a single student was able to successfully complete a lab. The instructor's only fault in this was that he did not stay up nights and weekends compensating for the failures of the courseware/NetBeans issues.

  
  This isn't really a NetBeans complaint--it's about pushing an IDE into the classroom without taking the proper amount of time and effort to make it work in the best interest of the customer/learner.

  
  Again, I'm very biased about this, but learning theory is a passion (and profession) for me. I began teaching Java courses for Sun in 1998, and I'm currently responsible for 4 of the top 5 selling Java books on Amazon right now... and none of these books use an IDE. I'm also the original founder of Javaranch, and jwenting made the (in my opinion dead on) observation that a quick scan through the forums turns up so many problems fueled by what the IDE hid or "protected" the programmers from.

  
  I do agree with you that one can do a great job of teaching Java to beginners using an IDE--but to have those students leave with the level of understanding they need of classpaths, etc. would take a far better teacher than me.

  
  Thanks for the opportunity to complain about this publicly ; )

  Posted by: kathysierra on February 23, 2007 at 03:07 PM

• Somehow this whole argument is skewed. It's full of red-herrings and pseudo arguments.

  But before I continue, disclosure: I work on educational tools, among them BlueJ, an educational IDE. So I'm heavily biased.

  The reason for my disquiet with this argument is this: The statments "IDEs are bad for learning" or "tools making us dumb" imply, without stating it explicitly, that all the possible tools in question are essentially (for the purpose of this discussion) the same. They are not.

  Furthermore, statements like "IDEs are too complicated (distracting, etc) -- I start my teaching with TextPad and the command line. Students should not use an IDE." has a big gaping hole of logic in it.

  By sayin "no IDE" it sounds like "doing less", which implies "easier". But is it really?

  Whatever you do, you are always using an environment. If you use the command line and a text editor, then that's your environment. (Not "integrated", but an environment nonethless.) And students have to master (to a certain degree) that environment. The implicit assumption that a command line has no learning overhead is wrong.

  To make a convincing argument that this approach is better for student, it's not sufficient to say "I'm not using an environment, therefore it's easier." One would have to argue that a command line/text editor environment is easier to use and/or educationally more valuable than any available IDE. (Note: Not easier than _one_ IDE, but easier than _all_ available IDEs.)

  The other fault in the argument is that the term "IDE" is, in many people's minds, equated with "huge, complicated system, GUI building, automatic code generation, etc.".

  The IDE we have built for students is _made for students_ ( www.buej.org ). It is NOT complicated, it does NOT have a GUI builder, it does NOT generate code, it is NOT huge and hard to learn. In fact, I would claim that a beginner can learn BlueJ much more easily than learning to master the file system and class path settings via a command line. You have to present a convincing argument against this to make your point.

  Furthermore, BlueJ offers educational tools such as visualisations of program structures, visualisation of classes and objects, interactive instantiation of objects, interactive invocation of any public method of objects, and a few others.

  These are tools that have been specifically developed for teaching, and have proven immensely useful. Teaching with a command line gives you none of this.

  Instead, while students should be thinking about programming concepts, they have to fiddle with environment variables, classpath definitions, typing ot not typing the right filename suffix, the Windows registry, folder strucures, etc. I have seen students stumbling on all of these, and none of this has anything to do with generic programming concepts.

  The argument against IDEs states (roughly) that "IDEs are bad for students" and then goes on to prove the point by looking at student experiences with NetBeans or Eclipse. That's like saying children shouldn't use a knife at dinner, and then proves the point by stating what bad things could happen with children and hunting knives.

  Well, then don't give them a hunting knife - give them a children's knife! But let them learn! (And let them cut their potatoes...)

  NetBeans and Eclpise are made for professionals. There _are_ IDEs made for students, and thay are quite different.

  And I am deeply convinced that they are a MUCH better learning environments than a command line. With a plain text editor and a command line, you are depriving students of a whole range of valuable learning experiences.

  BlueJ has been used for years by many hundreds of institutions. And I have yet to meet a teacher who wants to go back to a command line.

  The argument "My students are having problems with Eclpise. Eclipse is and IDE. Therefore IDEs are bad" does have a logical flaw.

  Sorry for the rant, but it's one of my pet peeves...

  Feel free to rant back,

  Michael
  --
  Michael Kölling
  University of Kent

  Posted by: mkolling on February 23, 2007 at 04:49 PM

• I agree that NetBeans' use of Ant is flawed. I'd much prefer a short, declarative project description (sure, in plain text of some sort).

  Posted by: tompalmer on February 23, 2007 at 10:22 PM

• I strongly support the use of student-level IDEs, rather than throw them into the command line / classpath environment, which is unfamiliar to many of them. DrJava, JCreator, etc are reasonable choices. BlueJ is arguably superior, but it's different, and therefore I
  don't happen to know exactly where the students are going to have problems. Not the best reason, but ...

  
  For my own work I use NetBeans, but it isn't student friendly enough for beginners (and I have tried it with them). By the second programming course the better students are using NB or Eclipse.

  This is in support of Michael Koelling's post, and I might point
  others to his excellent book on learning Java in BlueJ.
  

  Posted by: fredswartz on February 24, 2007 at 12:37 PM

• "In fact, I would claim that a beginner can learn BlueJ much more easily than learning to master the file system and class path settings via a command line." Which is one of the big causes of problems those kids encounter later on. They try to run or compile a Java program somewhere else where they have no access to BlueJ and fail because they don't know anything about classpaths, command line tools, etc..
  They learned the tool rather than the language.
  "Instead, while students should be thinking about programming concepts, they have to fiddle with environment variables, classpath definitions, typing ot not typing the right filename suffix, the Windows registry, folder strucures, etc. I have seen students stumbling on all of these, and none of this has anything to do with generic programming concepts. "
  If they don't know how to do that (and I've rarely had to "fiddle with the Windows registry", only after installing something like Oracle which corrupts your existing JVM settings) they will not be able to survive in the real world, so hiding them from it in the early stages means doing them a disservice. Of course many of those kids have no interest at all in ever doing any real programming once they have the course credits, but that just means that teaching them at all is an exercise in futility and the tools used are completely irrelevant as the students aren't interested in the course material.
  "And I am deeply convinced that they are a MUCH better learning environments than a command line. With a plain text editor and a command line, you are depriving students of a whole range of valuable learning experiences. " And providing them with another whole range of valuable learning experiences. Maybe 10 years ago that wasn't needed as students were used to using commandline tools and file system settings directly, something required if you ever go program for real (rather than just as a student or teacher), but that's no longer the case. I've seen kids surprised there even was a commandline, completely lost as to what to do with it. If they didn't have a button to do something, they failed misserably. That's a failure of their education right there.
  "BlueJ has been used for years by many hundreds of institutions. And I have yet to meet a teacher who wants to go back to a command line. " Most teachers never encounter their students after the course completes, so they don't see the problems those students run into. Those teachers that do generally have an industry background (rather than having worked all their lifes in the ivory tower of education) and aren't using BlueJ in the first place so you won't meet them. So you only meet teachers who are themselves flawed in what they feel their students should know.
  "strongly support the use of student-level IDEs, rather than throw them into the command line / classpath environment, which is unfamiliar to many of them." They should be taught to use it properly (and that should take just an hour or so to give them the level of understanding needed to run a Java compiler or runtime, change and create directories, and set environment options) exactly because they're unfamiliar with it. Not teaching them skills they'll require during their careers is a major flaw in your curiculum.

  Posted by: jwenting on February 25, 2007 at 08:55 PM

• Do we still need reinvent the wheels again and again? I wouldn't against that to teach the students the low level knowledges and theories, but it depends whom you are teaching to, if it's the web app developer, probably you need give 'em the productive IDE and tech 'em the design stuff. why care about that too much? Do we still need write assembly code today? C code? For someone's work, yes, they are writing drivers. For rest of us, no. We are writing the web based apps, we just need the right tool to do the job. and be productive.

  Posted by: mikevan on February 25, 2007 at 10:50 PM

• A big problem I see with both university and professional training is they focus on just the technology or just the tools, rarely both. Worse yet, I've seem lots of classes that were supposed to be about technology but were about tools. But you will never master the tools without understand the technology inside, and you'll never be productive using the technology without good tools. So students (and pros) are left by thenselves to get the other half of the knowledge they expected to get either from professional training or university classes.

  You can have great results using an IDE (or command line) if you reserve time focused on the tools thenselves, and everytime clearly separates what's about the tools and what's about technology. It works better if you change tools from time to time so students can see the technology per se at work and understand the IDE role in the process. Say, start with command-line, then use an IDE, and later focus on Ant and Maven outside the IDE. This mean you have to provide extra time for each different tool, and not try to teach any tool at the same time you are teaching a new API or technology concept. Planning good classes is as hard as managing a software development project. That is, when you introduce a new tool, use somehting you've already done using the previous one.

  Using those practices, I got good results teaching using both command-line, NetBeans, Eclipse and BlueJ, in academia as well as in corporations. Of course nothing will yeld good results when your students just want to earn credits to graduate, or just want to enhance their resume. Lack if interest by students and pros is a bigger problem today than choosing the right tools for teaching. :-(

  Posted by: flozano on February 26, 2007 at 08:56 AM

• @kathysierra:
  Thanks for the feedback. One specific comment:
  >This isn't really a NetBeans complaint--it's about pushing an IDE into the classroom without taking the proper amount of time and effort to make it work in the best interest of the customer/learner.
  Agreed. The first round of adding NetBeans to the labs started in the fall of 2005 and the modified courses were rolled out starting in early 2006, using NetBeans IDE 5.0. And quite frankly, some of the lab materials were not very student or instructor friendly. This is a direct result of too much work being attempted in too short a time frame given the available resources. I pushed for a reduction in scope - specifically, that the conversion of at least one of the courses be deferred. But my advice was not followed. The instructors and the students ended up paying the price - I monitor the instructor email alias so I know what they went through.
  In the last few months the process of revising the courses for Java EE 5 has started to produce some results. Part of the change is the switch to NetBeans IDE 5.5. I have not been as directly involved this time around, but from what I can tell, it appears that quality has improved in these latest versions. If you are still seeing problems with the EE 5 versions of a course, then please speak up. You have plenty of contacts, but if all else fails send me an email. :-)
  

  Posted by: gsporar on February 26, 2007 at 06:51 PM

• @flozano:
  >and later focus on Ant and Maven outside the IDE.
  Agreed, but that brings up an interesting point. One of the complaints that I have heard from instructors is that the IDE "hides too much" of what happens in the web/EJB courses when it comes time to deploy an application. But before the courses were converted to use NetBeans in the labs, they were heavily dependent on running Ant from the command line. So I don't see much difference - the real work is being done in an Ant target that the student may or may not understand, depending upon how much time the instructor has to explain those sorts of things.
  >Lack if interest by students and pros is a bigger problem today than choosing the right tools for teaching. :-(
  Agreed. And from what I have heard, there is another common problem: students who do not have the prerequisite experience for a course. The horror stories I hear are pretty bad: students who have never written any Java code show up for advanced EJB courses. In a situation like that, I don't think it will matter what tools are used or not used.
  I suspect in most cases the training budget was just not large enough. So the pointy-haired manager said: "Go read a book over the weekend to cover the prerequisite stuff and then show up on Monday for this advanced course."

  Posted by: gsporar on February 26, 2007 at 07:00 PM

• @ jwenting

  
  >> "In fact, I would claim that a beginner can learn BlueJ much more easily than
  >> learning to master the file system and class path settings via a command line."
  > Which is one of the big causes of problems those kids encounter later on. They try
  > to run or compile a Java program somewhere else where they have no access to
  > BlueJ and fail because they don't know anything about classpaths, command line
  > tools, etc..

  This is completely misunderstanding the argument.

  The argument is what to do *first*, not about what to do, full stop. Of course, no student leaves our institution without having programmed from the command line, or having programmed in a professional IDE. But they start in an educational IDE.

  You are making a whole string of claims based on assuptions about what I do or do not teach, most of which are completly incorrect.

  Michael
  

  Posted by: mkolling on February 27, 2007 at 01:13 AM

• Whether students end up learning the tool or the technology does not depend on whether or not an IDE is used in the classroom. It depends on HOW it is used. I've attended both SL-275 and FJ-310, both courses given by Sun, one a beginner's course and the other focused on web technologies. In both cases, the success of the course depended not on the IDE, not on the courseware, but on the quality of the teacher him/herself. That's what always ends up being the deciding factor. A good quality teacher will understand the value of an IDE and use it appropriately, prefacing the IDE usage with clear and incisive instruction on the underlying conceptual understanding of the technology involved.

  Posted by: geertjan on February 27, 2007 at 08:48 AM

This work is licensed under a Creative Commons License.