GPS Systems and IDEs: Helpful or Harmful?

Every time I visit the Boston area, I am reminded of how nice it is to have easy access to GPS navigation. GPS often enables me to get places faster and with more confidence than I would otherwise have. However, use of GPS is not without its issues. First, the GPS directions are not always the best directions and are sometimes even downright wrong. Second, I have found that I do not learn how to get around as well as I do when I use a map (or even a map with directions produced by MapQuest or Google Maps) and pay more attention to street signs myself and make my own decisions. Like using the portable GPS device to generally make navigation easier, IDEs and other tools can be very helpful in making it easier to develop software. However, like GPS tools, IDEs are not without their disadvantages.

The directions provided by my GPS navigation device are usually correct in terms of getting me to the desired location, but are not always the optimal directions. When I am in an area with a very complex street system that I don’t know well (such as the Greater Boston area), I am willing to make the occasional sacrifice of less optimal directions in trade for the benefit of the GPS device nearly always getting me where I need to go. If I’m in an area I know well, however, I occasionally find that I can do a little better without the GPS. In such cases, I forgo use of GPS because it is not helpful and can actually be slightly harmful.

Use of the IDE is similar to use of the GPS navigation system. Most of the time, it is a great help, but there are times when I can actually do better without it. This is especially true when it is code that I know well or code that I need to make a small already identified fix to. I find it is often easier to load that up in vim quickly and make the minor addition or edit then to wait for the IDE to load and to wait for dependencies to be built and checked.

I have found times when my GPS navigation system simply seems to “lose its mind” or runs into a situation in which it cannot be expected to “know” of extenuating circumstances. In such cases, I need to be familiar enough with reading maps and signs to adjust myself and figure out the correct route to my destination. Likewise with IDEs, there are times when the IDE simply cannot support something we need to do because it is too general for such a feature or because it just wasn’t expecting a certain type of support to be ever needed. IDEs support plug-in development to help with these specific cases, but it is not always feasible or practical or develop a new plug-in.

In the current java.net poll, a question is asked regarding use of a particular framework because it is included in an IDE. One respondent answered that it is his or her preference to not using an IDE with the desired framework support because of versioning conflicts (the version supported by the IDE is different than the version the developer needs to use). I have found situations exactly like what this respondent describes where the IDE support for a different version of my desired framework actually made it more difficult to use my version of the framework with that IDE. On the other hand, I have found the Spring integration features offered by Spring IDE and by Oracle Enterprise Pack for Eclipse to be very helpful in development with Spring framework.

A significant disadvantage (for me) of using GPS is that I don’t learn my way around a new city very well when I use GPS and let it do the “thinking” for me. This is not a big deal if I am only visiting a place once or if I can guarantee I’ll always have a working GPS navigation system with me. However, it is useful to know the area better if I will be visiting it frequently or if I may have to revisit without GPS. Also, as described above, there are times when better knowledge of the area is highly desirable because the GPS is wrong or does not provide the optimal solution.

Like GPS systems, the IDEs can lead to us knowing less about our environment. With GPS, I may be less likely to learn street names and freeway exits while with the IDE I may be less likely to learn the packaging structure of the libraries (including standard SDK) that I use often. As with the GPS system, this is less of an issue if I don’t use that library often or if I always have access to an IDE.

If I spend significant time in an area, I tend to learn my way around and need the GPS less, but for more focused things. I often don’t need the GPS at all for short and routine trips. I have found the same to be true of IDEs; I prefer not to use them for short and routine pieces of code because the overheard is not worth the very little benefit derived in those situations. For instance, both gvim and JEdit provide color coded syntax without the significant overhead associated with most full IDEs.

I recall a time not too long ago when some developers argued against use of an IDE at all. I have never subscribed to that extreme of an approach. In fact, I generally use an IDE. That being stated, I personally find there are times when vim+Ant is enough for simple, routine tasks. Of course, this in no way means that everyone finds that approach better. I think it’s silly to argue that a developer is any less of a developer because of the percentage of the time he or she uses an IDE.

Just like the GPS, we should use the IDE when it is helpful and the benefits outweigh the costs. Because the perceived benefits and perceived costs of IDE or GPS use are different for different people, it is not surprising that we all have different preferences related to level of IDE usage.

While using the GPS here in the New England area, I’ve tried to invest a little additional effort to more carefully observe the street names and exits I need so that I can still learn how to get around the area. This does take a little more effort than simply blindly following the GPS’s pleasant sounding directions, but I think it will pay off in the long-term. Similarly with an IDE, I like to understand what it is doing underneath the covers when it does things for me. In particular, I still try to learn the basic packages of well-used classes in the JDK, Java EE SDK, Flex and other things I plan to use often in the future.

Just as I would have found it much more difficult to get around the New England area without GPS even though this was not my first time here, I still find that, in general, the IDE helps me be a more productive and efficient developer in the short-term and, if used appropriately, can help me in the long-term as well. I have recently had the opportunity to work with NetBeans 6.5, JDeveloper 11g, and Eclipse 3.4 (Ganymede) and have found all to be highly useful in development. I have heard and read many rave reviews for IntelliJ IDEA as well. We are very fortunate as Java developers to have such a wide variety of mature and productive tools at our disposal. However, even these great tools can sometimes be wrong, can sometimes provide less than optimal solutions, and sometimes simply cannot support what we need to do. In such cases, it is advantageous if we have not allowed ourselves to become completely and hopelessly dependent on the tool.