The IDEs are driving us crazy
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:
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:
- 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.
- 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:
documentation and communication stuff. Ask the team members to adopt it.
early alert you about the mess running underneath the CVS.
file encoding or proprietary code formating.
Unfortunately, people are not machines and eventually your project will fail because
someone was thinking about his girlfriend instead of code formating ;)
else thinking - someone that can think very differently from you.