Me and my IDE

Introduction

As customary in my articles on text editors and IDE I originally started this post with a self-condescending presentation of my skills and expertise. Then there have been some miscomprehension between chrome and blogger and the second part of the draft was not saved although blogger stated otherwise.

As a consequence I had the more self-condescending part and I lost the slightly more interesting one. I thought to do everybody a favor and delete that stuff. Now, a slightly less condescending paragraph on myself in order to motivate my point of view.

The past

I almost always used editors. Emacs, vim… and when on BBEdit and TextMate. Ah… light tools. Not only that: I was quite vocal in the IDE vs. Editor war (from the editor side, of course). And this can also be related to my choice of  “freedom languages” (more on this on later posts, perhaps?).

But some weeks ago I realized that now, without noticing, I’m mostly using IDEs. How has that happened? The easy part to explain is the Java related one. Java greatly benefits from IDEs (or perhaps the widespread diffusion of IDEs has tampered the development of good language features?); in fact it is quite much harder to develop Java without an IDE, since the language is very verbose. On the other hand its restrictions and bounds make it quite easier to develop good and powerful tools. Of course I could use UltraEdit on Windows… but no luck with OS X and Linux (moreover, I had to pay that as well… and I preferred to buy IntelliJ).

Emacs has very nice modules to work with Java. On the other hand they have to be installed separately (and in my experience also slowed down normal operations). When I have to loose to much time configuring my editor, I usually try other solutions. That is why I used TextMate and BBEdit extensively… because they are almost already set-up. I also like vim, since has decent default setups for most situations.

For somewhat similar reasons, I bought WingIDE to work with Python. I could set up Emacs (or vim) to do that stuff, of course. Still, I had not much time, not motivation… and I bought the thing. I especially liked it because it worked equally well on single files and on large projects. It also had the best auto-completion for Python I ever tried, nice debugging features (I use them rarely, but when I do I love to have an easy to use environment, especially because I use them rarely and I tend to forget the tricks). In the pack there is also nice support for unit-testing (and that is a definite plus).

In the same time I worked extensively with C++. I mostly used editors (vim, because I especially like it with C/C++) and BBEdit because of its easy to set up “project management” features. BBEdit also has most the processing power of classical editors and that is nice. I quite enjoyed the best effort auto-completion it provided and ctags based stuff. Ok… still too much template metaprogramming (or simply correct and not basic use of templates) crippled smart “IDE like” features which I would have liked.

In other words, I sincerely craved for a nice C++ IDE. Perhaps I should try Java based IDEs with C++ as well… I may be surprised. Though I hate setting up projects in IDEs. Every IDE has its conventions and it is not always immediate how to work with a project that both needs “classical command line build interface” (which is something I’m not disposed – nor can I afford to – lose) and the IDE based build. Somewhat CMake eases the problem, but at the price of restricting myself to the supported IDEs.

Other languages I use, but I think that they account for less than 30% of my development time (and it is going to drop). And perhaps they could be moved to IDEs as well… as soon as I solve the “single file project problem” [or I simply give up my hopes with that].

This basically rules me out from editor flame-wars. Still, I believe that learning using IDEs is a terrible mistake… but is a modest position. Moreover, nowadays most editor proponents show you how to add all the IDE features to their editor of choice. So what’s the point? It’s not an Editor vs. IDE matter, it’s Emacs vs. Eclipse. And somewhat I believe Eclipse is going to become what Emacs was in the past years. And hopefully it is going to become faster like Emacs did…

The future

So what now? I’m lazy to the bone. And I’m quite new to the IDE world. I have my habits and I don’t really want to change them. And don’t believe the ones who tell that using IDEs is easier. Nor faster. It depends on your skill set. As I have my own requirements, some things may be slower with IDEs, at least until I figure out how to do them.

Which basically means that an IDE is not automatically more productive: it may be, provided that you know the tool. Yes, some have a very good learning curve (like WingIDE), others are very good, but need you to figure the way they work to exploit them fully (IntelliJ). Moreover, I still have to figure out how to develop Java projects easily built both with IDEs and with command line tools. Perhaps I should explore maven (which should be well integrated with all the main IDEs). After-all its racist on my part to spend time with cmake and auto-tools and not doing that for Java “based” projects.

Productivity metrics

Many metric of productivity, code quality and similar stuff have been proposed during the years. Usually each metric has some underlying implication on how software engineering and development should or should not be done. Some are so biased that they seem created only to promote a given procedure. Well, everyone has its jobs. There are people who code, people who tell other people how to code, people who tell other people how to tell other people how to code. The things stops here because even managers understand that a fourth level of indirection is a pure waste of money.

What we know is that good developers are just more productive that bad ones. This was well known even before the whole agile movement came into existence (and even before free software was a buzzworld). In fact I found references on this in Mythical Man Month, between a praise to God and another[0]. Basically Brooks cites some studies which proved that a good developer can be 10 times more productive than a regular one. Of course I would be led to think that a 5 good developer team could achieve much more than a 50 regular developers teams because of the minor impact of communication overhead (especially considering Agile techniques, but now I'm going astray).

Of course, the number of wtf code reviewers utter gives a roughly idea on the quality of examined code... and it works independently on the number of people in the team; it does not matter how many people wrote the cr... code. If it sucks, it sucks. If it sucks it will yield a sensible and continuous stream of wtf. The actual problem is that: i) you actually need a reviewer [which you should have, but too many companies don't]; ii) you actually have to put up recording systems and tie audio files with commits, which would require huge amount of space. Simply counting the number of wtf I don't believe it works, as tone counts. There is a mild wtf and there is an astonished wtf. And there is the angy wtf. And basically you have to develop a very complex system to discern the tone and texture and mood of wtf.

Thus, here we propose the FLOC metric (Fun per Line of Code). That is to say: how much fun the developer (in a sober state) had writing the code. Unless the developer has some facial paresis which makes him look as he was smiling all the time (which is something which luckily affects only a relatively minor percentage of programmers), only a crappy jpeg needs to be associated with the commit. Software which are able to do emotion recognition from face pictures is being actively developed and its not rocket science (actually rocket, have faces, sometimes, but I find extremely bad taste when soldier paint women on bombs).

Please notice I'm half serious: if developers have fun (such as when they program in some nice freedom language) they just write better code. And work longer. Produce more. Crap! That was a secret!

----
[0] I really understand why it is considered the "Bible" of software engineering, it is because the ratio of references to God per sentence is similar to the one we find in the Bible... which I don't think it's a problem in the Bible (since it's about God), but is awkward in software engineering. To understand my feelings, consider this scenario:
[user] Can the bridge support my truck?
[engineer] God bless you.