Skip to main content

The IDEs are driving us crazy

Posted by felipegaucho on February 9, 2006 at 3:13 PM EST

Activities Report #02:

Planet Earth, 2006 A.D.
Workstation: java.net
Module: Cejug-Classifieds
Status: active
MEMBERS PROFILE:
orrego: Spanish native speaker. OS: MacOS 3.1. IDE: Sun Studio Creator.
rajesh_sannareddy: Indish native speaker. OS: Linux 3.1. IDE: Eclipse.
java.net robot: en_US default locale. OS: Solaris. IDE: console.
raphael_paiva: Portuguese native speaker. OS: Windows 2000. IDE: MyEclipse.
felipegaucho: Portuguese native speaker. OS: Windows XP. IDE: WTP 0.7.
Date: Time: From: Entry:
01, Wednesday11:30pmCHILEorrego modifies some presentation files and commits to the CVS repository.
02, Thursday1:00amINDIArajesh_sannareddy update the controller in order to show the new features on the web.
02, Thursday1:30amUSAjava.net cruise control robot triggers the integration tests. Snapshot release is published on the test server.
03, Friday8:15pmBRAZILfelipegaucho tries the snapshot and gets several usability problems. Flushed characters suggest encoding problems in the files stored into the CVS repository.
04, Saturday9:00amBRAZILraphael_paiva fixes the character encoding. He send a mail to the team asking why the code still formated with 80 columns Line Wrapping.
04, Saturday9:30amUSAjava.net cruise control robot triggers the integration tests. Snapshot release is published on the test server.
04, Saturday2:10pmBRAZILfelipegaucho tries the snapshot release and notice that all features were working ok. The snapshot release is published on the project web site. The team receives a mail about encoding - the source of the problem is still unknown

If you had patient to observe the above report, you noticed some messy running on the code produced by the project team during february. The scenario is simple:

My project has members from many countries in the world, everyone using a different IDE, a different operational system and speaking a different idiom. All the people are motivated to do the best to put the project in the right way, but this Babel of tools are causing much more problems than solutions.

Seems familiar ? I guess so because almost every project I ever seen in my life suffers from configuration problems. If you are a member of a project in which every person could choose his own development environment, I'm sure you have painfull experiences with the code-style, integration and even the project communication. It is so common I decided to register this situation here in my blog.

Two other recent situations I experienced in my projects:

  1. The project I'm working uses a modified template where the Line Wrapper was modified to 255 columns, instead of the traditional 80 columns. One week of good job and I decided to update my IDE - I installed the new version in my computer and keep working on the code. Few days later a colleague asked me: did you change the Line Wrapping rule?. Of course, as human being, I was tired and also excited with the new version of my IDE - and I simply forgot to redefine its defaults before start working.
  2. A member of my Open Source project decided to contribute - he updated the CVS snapshot and fixed several open issues. Great job, unless a mute trap - the IDE he was using adopted the file encoding of his operational system, completely different from the project defaults. Nowadays, the project has part of its code in UTF-8 and part of it in Cp1252.

Machines: please don't think, just obey

The configuration problems seem ontological to computing and I can't imagine great solutions without much human interference. Despite that, several IDE vendors are designing heuristics to provide their IDEs the ability to guess what the humans are trying to do. This comfortable feature causes lazyness and ignorance about the development details - such as file encoding or code-style, for example. When a machine start taking decisions instead to ask the person what to do, the problems start. I think friendly IDEs as a great stuff, but it should be less pretentious about their ability to help us in our duties.

Some ideas: project descriptors like the ones used by Maven seem a great idea and something like that could be available for the IDEs. Imagine for a minute a specification of a XML Schema created by a consortium of IDE providers, in order to unify the project descriptors. Imagine now that every IDE forces the user to inform this default project descriptor in order to start a new project. Wonderful ? I guess so. Unfortunately, it seems far beyond the reality. For now, all responsability to reconfigure every new tools is still on humans and, you know, humans are not perfect.

Until we can figure out a solution for configuration problems, I enumerated a sanity checklist to help you to keep your team working together - if you know smart ways to avoid configuration problems, please let us to know.

Tricks to keep the team sanity:

  • Be simple - don't reinvent specifications unless you have a serious reason to do that.
  • Create templates for all kind of documents, including source code, documentation and communication stuff. Ask the team members to adopt it.
  • Use Ant, Maven or any console builder tool. Keep away the IDEs from your builds.
  • Use some continuous integration tool, such cruisecontrol or luntbuild - it will early alert you about the mess running underneath the CVS.
  • If possible, create alerts for the most common mistakes induced by the IDEs, such as file encoding or proprietary code formating.
  • Be patient, for now we depend on human memory to keep the things working on. Unfortunately, people are not machines and eventually your project will fail because someone was thinking about his girlfriend instead of code formating ;)
  • Don't confuse friendly IDEs with intelligence, they are simulacrum of someone else thinking - someone that can think very differently from you.

    • Related Topics >>
    Blog Links >>