The IDE Syndrome

The IDE Syndrome 1 A common complaint I get a lot at Grails Brasil is about the lack of support for Grails on the major IDE’s. Well, I really don’t see it as a problem, but actually as a solution for another much more serious one, which I usually call “The IDE Syndrome”.

If you feel more than one of the symptoms above watch out: you probably are “infected” and maybe doesn’t even know it!

Symptoms

  • Difficulty to adapt to other IDEs (classical example: those who are used to Netbans usually hate Eclipse and vice-versa)
  • You’re able to build your applications using the wizards/tools of your IDE, but don’t know actually how the frameworks/libraries in which your application is based actually work.
    (good example: you always use the visual editor of your IDE to build your JSF pages but don’t know how the JSF tags work)
  • Most of your tasks are done using the wizards/tools of your IDE or a lot of “drag and drop”.

    WARNING: In this case there’s a 99% of chance that you’re infected

An IDE can make your job easier, but it won’t actually do it for you

This is the greatest mistake in my opinion, and I know lot’s of people who actually believe in it. An IDE is created to make easier the use of other programming tools and frameworks, but they aren’t actually made to do your job! Have you ever heard the question “do you code in (your favorite IDE here)?”?

The implementation process goes beyond drags, drops and wizards. You know that, I know that, but I can see many “developers” which don’t. An IDE can create the illusion that software development is easy, but actually what is being created is the illusion of power.

In this case, there are two question that you should make to yourself: if the answer is “no” to any of these, well: again: you’re infected.

Do you really know how the frameworks/language/environment you’re using on your application work?

Can you work without code completition?
(I know many people that don’t (!!!))

Can you do your job without your IDE?

The IDE offers a work methodology which not necessary is the best of all or the only one

This is one of my major concerns about getting addicted to an IDE. When an IDE is being developed, it  is based on a set of principles accepted by those responsible for it’s development, which not necessarily are the only ones available.

Yes, usually is a highly efficient way of getting things done, but it’s not the only one. I think that it’s really important for a developer to know as many ways of doing it’s job as possible: even if some of these are worse than those offered by your IDE.

Someone used to work only with Netbeans for example may know only one building tool: Ant, and ignore completely other options like GANT, Maven, etc. (I know that there are plugins for these other tools too. But the fact is that usually the average IDE addicted doesn’t use them). Actually, Netbeans does such a great job on this part that is highly possible that an IDE addicted doesn’t even know that there’s something called “ant” at all!

An IDE is actually an abstraction of a set of knowledges/tools

As a consequence, those addicted to an IDE only know the abstraction, not the subjacent technologies behind it.

And here comes the leaking abstraction phenomenon, best described by Joel Spolsky in his article The Law of Leaky Abstractions. Every abstraction have limitations. As a consequence, there’ll be a moment in which it won’t work for unpredictable behaviors. So, it’s inevitable that some day things won’t work as expected for the IDE addicted. Oh oh!

So, should I avoid an IDE?

Of course not!!! It’s plain stupid to avoid what can make your life easier! What you should avoid is getting the illusion that all you need to know to get your job done is how to work with your IDE. Remember: it’s only an abstraction.

Believe-me there’s life (a lot of actually!)  without an IDE :)

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.