The economics of application installation

by Sean McGrath

July 28, 2003 —

Let's play a numbers game:

1) Think of a number that approximates the cost per hour to your
organization of one of your top IT professionals.

2) Think of a number that approximates the number of hours that person
spends in an average month fighting with problems involving words like
"path", "classpath", "registry", "shared library" or "dll" while
installing applications.

3) Multiply those two numbers to get the product X.

4) Now think of a number that approximates the dollar cost of a gigabyte
of disk space. (Hint 1 dollar is a good number here[1].) Call that
number Y.

5) Divide X by Y.

Let's compare numbers. I arrived at a figure in the hundreds of
gigabytes. You too? I thought so. Interesting isn't it? Skilled IT staff
are worth many hundreds of gigabytes of disk space *per day*.

How ironic then, that developers regularly waste the dollar equivalent
of hundreds of gigabytes of disk space, debugging problems that could be
solved with the addition of a mere handful of gigabytes of disk space.

It seems to me that IT professionals spend an inordinate amount of time
debugging problems that can be traced back to an anachronism in the way
applications are built. The anachronism is the notion that disk space is
more expensive than the person-hour cost of the poor customer installing
the application. That used to be the case but is not the case any more.

The terms I mentioned earlier, namely, "path", "classpath", "registry",
"shared library" and "dll" strike fear into the hearts of many. They are
the source of a seemingly endless parade of application configuration
problems - problems that often take hours of highly skilled developer
time to debug.

These concepts share a common theme - sharing of application program
components. This is considered desirable in order to minimize disk space
on a per-application basis and remove duplication. Unfortunately,
removing the duplication introduces a tight coupling between
applications which is at the root of many application installation
problems. We save some disk space but only at the expense of hours of
debugging time. The economics of it just don't add up.

In a world where a gigabyte of disk space costs less than a cup of
coffee, why do developers regularly spend hours of expensive time
(drinking multiple cups of coffee) in order to sort out problems that
only exist because of a misplaced desire to save a gigabyte of disk
space?

I think the answer to application configuration hell is to adopt a
pragmatic approach to duplication and "waste" of disk space. Ideally, we
would have simple tools to allow us to manage pragmatic duplication
rather than complex tools that allow us to manage anachronistic
"optimal" disk usage.

In my mind's eye, I see an installation system based on Unix's chroot
concept (for establishing virtual hierarchies for applications) and
Unix's symbolic link concept (for managed duplication). I see a world in
which every Java application has its own JVM, its own JDK, its own copy
of *everything* all in a nice tidy directory - a truly self contained
world.

Why not? It would waste a few gigabytes? In the time it has taken you to
read this article you have probably been paid the equivalent of many
gigabytes of disk space.

If simple economics prevail, the days of classpath and "dll hell" should
be numbered.

[1] http://www.acmqueue.org/modules.php?name=Content&pa=showpage&pid=43

ITworld