The Dilbert Principle?

Rohit Khare (
Mon, 8 Apr 96 01:19:19 -0400

Begin forwarded message:

Resent-Date: Mon, 08 Apr 1996 00:00:44 -0500
In-Reply-To: Your message of "Sun, 07 Apr 1996 23:28:11 CDT."
Date: Mon, 08 Apr 1996 00:00:44 -0500
From: "Douglas C. Schmidt" <>
X-Mailing-List: <> archive/latest/466

> But large corporations still seem to believe that essentially one
> salary fits all (except for years of servitude). Wouldn't it be
> ironic if Software Science did develop some good metrics that were
> accurate enough that no one would compute them because they were too
> embarrassing?

That's a very keen insight. Most unsuccessful software organizations
I've been involved with over the years have had the misconception that
developers were interchangeable and could be replaced easily. I've
seen this attitude most frequently at companies where technology and
computing is viewed as a "back office" function or as a "necessary
evil" required to remain competitive. In these environments, software
developers are often referred to as "coders," which implies that
programming is a rote, mechanical activity (hum, sounds similar to the
arguments of our "translationalist" colleagues... ;-)).

Another manifestation of this phenonemon occurs in organizations where
technical hiring decisions are not made by the technical staff. I've
worked with several companies that operated by the general principle
of "least expensive employees get the job." Not surprisingly, this
resulted in an environment with high turnover rates and an inability
to produce high quality and maintainable software architectures,
designs, and implementations.

As usual, you get what you pay for. Although the irony of this
particular situation is that companies are often willing to pay a
mucher large aggregate amount of $$$ for armies of low-cost,
low-productivity software developers, rather than a smaller aggregate
amount of $$$ for a few high-high, high-productivity developers. I
guess that's another example of the Dilbert Principle...