Corporate Information Factory (CIF) Resources by Bill Inmon, Inmon Data Systems

> home > view content

Where Have All The Application Developers Gone?

By W. H. Inmon

Once upon a time there were application programmers. Every self-respecting IT organization staff had the sensible organizational chart that contained the following:

Systems programming
Applications programming
Maintenance programming
Miscellaneous, including

Education
Facilities support
Documentation and libraries, and so forth.

But today you wake up – and just like Rip Van Winkle after a twenty-year snooze – you find that things have changed dramatically. Why, look! There’s no more application development organization!

Now does this mean that there are no more applications? Not at all! There are applications more than ever before. It’s just that those applications are not being developed and maintained by the IT organization. Instead, we find that:

Applications are being developed and maintained inside the end user organization. End users have their own PC, hardware, software, and data, and have long been estranged from the IT department,
Applications that have been developed in the past are left in a heap called the “legacy systems environment.” It is a fate worse than death to be banished to doing work here. If there ever were a dead end career, it is in the maintenance of old legacy systems,
Applications with any custom development are being done in India. It is much more economic to ship problems overseas than it is to solve the problems here in the US,
Applications are developed by outside consulting firms,
ERP software has taken over and permeated the applications that are being run today. The real development and maintenance is taking place in Walldorf, Germany and Pleasanton, California. You want to see a real developer? You certainly can’t find one in the halls of the IT organization.

So applications today are being developed and maintained a long, long way from Main Street, USA. The IT organization has lost its will and skills to do development. Today’s IT staff has become an organization of caretakers and evaluators of technology; development skills have long departed.

Why exactly have these skills left the organization? There are a whole host of complex and interrelated reasons for the departure of development, including:

Economic. It is much less expensive in the long haul to farm out the development tasks than it is to staff and feed an in-house development and maintenance staff,
Technical skills. Real development talent is hard to come by. There never were enough skills to go around, and as time passes, there is increasingly less talent to fill the needs of the organization,
Technology has been “dumbed down” to the point where end users can do their own work, without needing the intercession of a middleman,
Architectures have been created where all that is needed is data meeting end user. The need for the programmer has been abrogated,
Economies of scale allow an outside developer to build systems for many customers, rather than have everyone develop their own unique applications, and so forth.

There are then some important reasons why in-house development in the IT department is a myth in today’s world. There is another obscure and seemingly perfect, rational reason for the demise of the in-house development staff; the practice of adding more staff and development workers when a project starts to have problems.

In order to understand this phenomenon, consider the following.

On the surface, it seems perfectly normal and natural to add staff and resources to a project that is in trouble. A project is due to finish in October, for example. The manager tells the head of IT that the deadline will not be met, and so management adds staff to the project in order to make the deadline. What could be more natural? Isn’t that the way other parts of the organization are run?

By and large managers are paid and otherwise rewarded based on how many people they manage. If you manage a staff of five you are a project leader. If you manage a staff of five hundred, you are a director. And directors make a lot more money than project managers. That’s simply the way the world turns.

Now consider two projects: project A is run by manager A and project B is run by manager B.

Both projects start out with five people on board. Project B is well run and finishes all deliverables on time. The end user is happy.

In the meantime, project A is running behind schedule. Five people are added to project A. Time passes and project A gets into further difficulties. Five more people are added, more time passes, and project A continues to flounder. By this time project B is already completed. Manager B and all the staff from project B are added to project A, working for the manager of project A.

A year later project A finally staggers across the finish line. Manager A now has fifty people working for him. He gets a raise commensurate with the management of a staff of fifty people. Project manager B gets a merit raise of 5%.

Something fundamental is wrong with this picture. The organization is grossly rewarding incompetence and penalizing competence. The people who make the biggest mistakes get the biggest rewards and the people who are the most competent get the biggest penalties.

Now this scenario may seem far-fetched, but it is anything but that. This is actually what happened. Bigger and bigger development efforts became staffed with more and more incompetent people. At some point, things ground completely to a dead stop.

Unfortunately the need for new systems did not stop. That’s where IT management started to see the end user go directly to the OLAP vendor. Or the ERP vendor. And soon IT was on the outside looking in. The budget was stripped away from IT and the era of competent external vendors was born.

There is another related issue and that is the law of large projects, which suggests, “spend enough money on a project and the project must be deemed a success because to say anything else would be political suicide, regardless of the reality of the development effort.” IT went around with its head in a bag. This worked for a while, but at some point, the end user became fed up with this charade. Enter the ERP vendor or the consulting firm and exit IT.

When reality enters its ugly head (and despite the best efforts of IT management, reality eventually wins), the IT department has been shown to be incapable of doing major new development.