"IT Departments Running on the Edge of Collapse"

There's a (short) interesting interview with Sun's James Gosling on C|Net today.  On the second page, discussing his desire to develop tools to help cut software development costs, he depressingly observes:

If you come up with a good software development tool, that makes life easier for the developers and they can get their job done quicker, then the first thing the manager says is "Oh you've got free time on your hands. Do this extra thing." ....

So pretty much every IT department will always be running right on the edge of collapse because if you ever get beyond the edge of collapse, you collapse, things fail, things fall apart. If you ever get on the other side, things get a little bit easy and people say "Oh we can do more."

In some sense I've resigned myself. In the land of tool builders like me, it's not about cutting IT costs as much as it is inevitably about enabling IT departments to do more.

He should be celebrating.  It's all about enablement.  Two ratios we seem destined to live since we started software programming are:

• The average number of lines of code written by an average developer per day
• The number of defects per thousand lines of code in a system

All our advances in languages and tools are about developing more (better) software by writing less code.   From higher level (compiled) languages, to modules, libraries, objects (and distributed objects), scripting languages, web services, visualization, configuration management, and automated build and delivery, it's all about enablement.  Every time we double the speed or transistor density of a chip, or the bandwidth on the Net, we come up with new and interesting applications to devour it.  So too with human capacity.

This is actually why free and open source software is such a fundamental software engineering friendly practice, and why sharing software (eventually through copyright) predates the FSF et al.  Good engineers develop systems to optimize for the scarcest resource.  The engineering efficiency and expediency of sharing known good building blocks and tools is obvious.  It's about preserving the value in the software, not destroying it.

Dr. Gosling is hopefully wildly pleased with his contributions!