Friday, October 28, 2005

Technology Snake Oil Part 6: Drowning in Tools

In my last Technology Snake Oil posting (Part 5: The Integration Myth), I talked about the more and more comprehensive IDE's and the bundling together of more and more tools. I think that Microsoft Office and Visual Studio point to a disturbing, Borg-like trend. It doesn’t matter if none of the tools is the very best at what it does, as long as it works nicely with all the other tools in the suite.

The problem we have in the development world is that we are drowning in tools. The “bit rot” problem in Windows is well known. The more software you install, the more likely there will be conflicts between components, the slower it gets, and the flakiness level rises. I reached an interesting milestone recently. I had the opportunity to build my development laptop completely from scratch (no ghost images, everything installed in pristine state from CD's). Anticipating this momentous occasion, I compiled a list of all the tools that I thought I couldn't live without. Many of these tools are very special purpose (like WinMerge), many of them are open source, but they are all tools that I use, maybe not daily, but at least sometimes. Once I got everything installed, I started getting the kind of flaky behavior symptomatic of a bit-rotted Windows machine. I had reached a milestone: my basic working set is incompatible with Windows.

This led me to pare way down on the tools I use. Every tool has to defend its life, and make the cut to survive. I gave up some stand-alone editors (I have a text editor fetish, and formerly had a bunch of them, each for one or two things they did really well). Most of those chores have moved over to Emacs now. OK, and Notepadd++. And Crimson Editor. But that's it! I promise! I’ve been actively trying to cut down my working set.

Developers love software, and tend to accumulate a lot of it. In the pathological case, developers can spend more time installing, uninstalling, and trying to get integrations working between tools that they have no time left for productive work. I have to fight this tendency in myself to try new tools, because each one represents a shiny new object that will, according to its web site, be faster, lighter, more aerodynamic, and brighter, a floor wax and a dessert topping. Using an over-worn analogy, we have an entire wood working shop filled with expensive, gasoline powered, multi-purpose saw/drill/lathe/turnip twaddlers.

Instead of monolithic tools, we need very cohesive, modular tools. The Unix guys got it exactly right – create simple command line tools that follow a few conventions (like all input and output it unadorned text). They created independent, cohesive modules of behavior. Once you understand how these modules work, you can chain them together to achieve what you want. They even built in integration tools, like xargs (which lets you massage the unadorned text output from one program into the expected format of another). Without question, someone who understands how these tools work is more productive (with fewer headaches) than someone struggling to use a behemoth like Software Delivery Optimization. Why are the command line tools better? You can script them in nice clean ways, and let the computer do work for you. One of the unfortunate trends with graphical environments is the dumbing down of power users. If you watch how power users in the Unix world work vs. typical power users in the Windows world, the Windows guys (on average) are working a lot harder, performing a lot more repetitive tasks. We need a woodworking shop filled with simple hand tools, not more electricity and kerosene. Throw yourself a life preserver; download cygwin today.

5 comments:

Anonymous said...

Man, wouldn't it be cool if someone wrote a book on how to use all of these old tools?

:-)

I love seeing Emacs on your list.

-Joe

Anonymous said...

I agree. I get annoyed at all the things the IDE tries to do for you (e.g. delete a file from revision control when I'm just trying to replace it with a different copy). I find that I use the IDE for programming and the command line for various administration and configuration tasks.

I do think that there are some things that the IDE makes a lot easier. For example, sed from the command line works great for doing massive search and replace, but what if I only want to change some instances? It's nice to do it through the IDE where I can preview each change.

Throw yourself a life preserver; download cygwin today.

Better than that, stop trying to drown yourself by using Windows. Linux and Mac OS X are both developer friendly environments. I switched to Linux 3 years ago after never having used it, and I haven't looked back. Linux has come a long way in the past couple years to improve usability. The number of cross platform apps available is incredible.

Anonymous said...

Great resource, I an glad i found this blog. Keep up the good work.

Richard Jonas said...

I agree - I use the IDE to edit and compile programs, but I've found many things easier with standalone tools.

If things go wrong with the integrated IDE tools (such as with source control integration if two people have managed to check a file out simultaneously), it's often confusing and difficult to track the cause of the problem. Sometimes the IDE tries to be too clever, changing source code for you where you don't want it to be changed.

I think integrated tools are great if you have a "standard" project where you use them exactly as the manufacturer intended, but how many projects have you worked on that have been completely "standard"?

Anonymous said...

Hey, thanks for the info on lowcost web hosting , there is another site that may interest your readers it is Web Hosting Directory