Skip to main content

The IDEs are driving us crazy

Posted by felipegaucho on February 9, 2006 at 12:13 PM PST

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, Wednesday 11:30pm CHILE orrego modifies some presentation files and commits to the CVS repository.
02, Thursday 1:00am INDIA rajesh_sannareddy update the controller in order to show the new features on the web.
02, Thursday 1:30am USA java.net cruise control robot triggers the integration tests. Snapshot release is published on the test server.
03, Friday 8:15pm BRAZIL felipegaucho tries the snapshot and gets several usability problems. Flushed characters suggest encoding problems in the files stored into the CVS repository.
04, Saturday 9:00am BRAZIL raphael_paiva fixes the character encoding. He send a mail to the team asking why the code still formated with 80 columns Line Wrapping.
04, Saturday 9:30am USA java.net cruise control robot triggers the integration tests. Snapshot release is published on the test server.
04, Saturday 2:10pm BRAZIL felipegaucho 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 >>