January 05, 2007, 2:52 PM — When developing software in the old days, we used to grab a bunch of separate tools with names like compiler, linker, editor, profiler, debugger and hook them together with our fingers. That is, we installed them as individual applications and made them work together the way we wanted by organizing a working setup on the hard disks of our computer systems.
Over the years, this model seems to have undergone gradual but constant erosion in favor of a more monolithic approach to tooling in which large applications such as Microsoft Visual Studio[1] and Eclipse[2] taking center stage.
There are a number of interesting side-effects to this trend. First, it is resulting in a significant change in the market for developer tools. It is still possible to "go it alone" and develop stand-alone developer tools but increasingly, developer tools are being positioned as "add ons" or "plug-ins" to uber-tools such as Visual Studio and Eclipse.
Second, these tools are BIG. Big in size, big in scope, big in terms of feature sets, big in terms of the commitment required from developers to learn to wield them well. I do not think it is stretching credulity too much to say that the IDE used by an individual developer significantly impacts their world-view, their understanding of the software development process and their mental model for how complex stuff hangs together. Take a C++ developer out of one of these uber-tools and drop them into another uber-tool and you may well have to wait quite some time for their head to bob back up above the water line in terms of productivity.
Third, in order to be a good uber-tool you need to have an extensible set of graphical components so that plug-in developers can re-use existing code for creating outline views, color-coded editors, etc. Looking at it another way, a good uber-tool must - by definition - be a good custom application development framework. This creates an interesting dynamic in which an uber-tool aimed initially /primarily at software developers can find a home as a generic container for end user applications. I know of no better example of this phenomenon than the Eclipse Rich Client Profile[3]. The phrase "developed in Eclipse" has a potential interpretation quite unlike, say, "developed in Delphi"[4].
Fourth, the whooshing noise in the background is the sound of a race in full flow. A race to get developers on board using uber-tool X, Y or Z before the next guy gets there first. Why the rush? Well, generally speaking your average developer will use one of these uber-tools as the center of his or her universe for quite some time. The stakes are therefore quite high.
Fifth, as the center of gravity in the developer tools industry shifts to the uber-tools, it will become more and more difficult to stay outside of one of the big uber-tools. Pretty soon, complete projects set up for ubertool X,Y or Z will have the network effect of getting all developers on those projects to use the same uber-tool. Think of the 'office wars' on a smaller scale and to a very different audience you have the general flavor of it.
One final and largely uninteresting side-effect is that I have - partly as a consequence of the reasoning presented in this article - begun using an uber-tool (Eclipse as it happens). After years of avowing that I would never succumb to using one of those newfangled all-singing and all-dancing IDEs, here I am, dragging and dropping my way through a software development project.
My resistance was ultimately futile. Will I be happier? More productive? I don't know. Will I be less out of touch with 21st century software development realities? Yes.
[1] http://en.wikipedia.org/wiki/Visual_Studio
[2] http://www.eclipse.org/
