Moving the Curve

Moving The CurveThe problem of developing complex software is summarized in this set of curves.

The horizontal axis expresses the complexity of the system. To the left would be a simple decision-support query only application. On the far right would be highly complex, mission critical, 24×7 on-line transaction processing system like an air-lines reservation system.

The vertical axis shows how much it costs to implement the system in time and money.

Where the curve hits the vertical axis is how much it costs to begin development of even a small application. Think of this point as the ante required to play a hand at the table.

Three points are immediately obvious:

  • The curve which expresses the relationship between problem complexity and cost of solution will always be a hyperbole.
  • As the curve goes vertical, the incremental cost of new functionality (additional complexity) becomes significantly greater.
  • A lower the ante and a flatter the curve is better than a higher ante and a steep curve.

The curve labeled “1” is the cost of developing systems in the “traditional” way. Typically, this means a mainframe-based waterfall model. The characteristics of curve 1 are:

  • Developing even a simple system costs a lot;
  • It is possible to develop very large systems.

Along comes a new technology like client/server and its attendant tools like Visual Basic. You watch the demo of the tool in action and are absolutely stunned. In a matter of minutes, you see work done which would take weeks or even months using the curve 1 tool set and development methods.

Clearly this tool is superior to the “old stuff”, so you want to dive in and try it out. Maybe you build a small system a in the range expressed by “A” in the graph. And sure enough, you save lots of time and money.

So you try again with a system like “B”. Your results aren’t as good, but you still saved some time and money, so clearly this new stuff is better than the old way.

Thinking that curve two is actually curve three, senior management decides to go for the big enchilada and you shoot for system “C”. Two years and five million dollars later, they shut the project down and have no real idea what hit them. What failed?

This is a classical problem in change management: the tendency to trivialize complex problems and hope they will not bite you. The psychological term is denial.

Four things must happen to transform curve two into curve three:

  • The technology must have time to mature
  • The people must have time to learn new skills so they can use the technology effectively
  • New technologies and new skills require new processes and methods which take time to develop
  • The organization must evolve structurally

Maturing Technology

Technology takes time to mature. Versions one and two of Microsoft Windows were complete failures; however, version three sold 15 million copies in its first year.

Early versions of Visual Basic were very weak and limiting compared to the capabilities of their current versions.

Technology is the infrastructure upon which business solutions are built. If the technology isn’t ready yet, best to know this before you bet your business.

New Skills

Giving a great set of shop tools to someone who doesn’t know how to use them doesn’t turn that person into a cabinet maker. One of the common management failures is to assume that new tools will, by themselves, solve the problem.

Skills take time to evolve. Once a person has attended a one week class exposing them to a new tool, they are, at best, an educated novice. Learning to use the tool effectively can take many months. During this time, the developer will make lots of mistakes, some of which can be very costly.

The tool is only as effective as the person using it, and there is no way short of a Vulcan Mind Meld to speed up this process. It simply takes time.

New Processes

Building small applications can often be done with a rather ad-hoc development processes; however, building a large complex system is a complex process that requires many activities and tasks.

Many development methodologies like Andersen’s Method One exist in the “traditional” mainframe world, but a one-size-fits-all-but-some-steps-are-optional methodology doesn’t work well with the many different tools, processing architectures, application models and development styles of today’s world.

Creating a flexible and adaptable set of process models that can deal with a wide range of systems and technologies is a never-ending process in itself.

Growing the capabilities of development processes and methods requires iteration over time and must have a self-correction feedback mechanism built into it.

Creating the seeds of this process often requires a substantial culture shift, and sometimes even…

New Organizational Structures

The traditional monolithic centralized organizational structure of the typical Information Technology organization is too vertically integrated, too rigid and too separate from its users to meet today’s rapidly changing business needs.

It is possible to move from curve one to curve three, but it can’t happen overnight. You cannot simply decide to be at curve 3.  Getting there is a migration.  A wise manager will recognize the need for careful change management and plan the journey accordingly.

Last Updated on 10/29/2007

Print Friendly, PDF & Email