coneblog

Some feel that managing change is the central issue in systems development. I have always maintained that the central issue in systems development is communication. I’ll concede that, in the current environment, change issues increasingly dominate discussions of process. So lets talk about change.

First, a brief history of change (with apologies to John the Apostle):

In the beginning was the code, and the code was with the system, and the code was the system, and there was no part of the system that wasn’t code. The application was easily stated, requirements were simple, and change was a single-developer version control problem. It was a largely monolithic, large mainframe world, and the systems were simple update and tabulation systems, without user interfaces.

Then came CICS, the first widely used interactive data processing architecture. This was the “Cambrian Explosion” of systems complexity, where the analyst now had to contemplate how to craft a useful solution to a more complex problem. But the huge change was the introduction of “The User”. There was now a human, with all of its foibles, insufficiencies, and randomness, interacting DIRECTLY WITH THE COMPUTER in REAL TIME. I liken this to the introduction of the Apple by the serpent into the Garden of Eden.

Now requirements became complex, because the system interfaced directly with humans. Humans are complex beings that work on complex tasks. Humans want and need help with their tasks, but are often afraid of looking stupid or of losing control, or are just not paying attention. Except of course for Doctors, who don’t need any help.

From the analyst and developers viewpoint, the central issue was capturing complexity. I know this because I was there. The methodologies focused on different ways to manage more complexity – usually through some type of decomposition of complex tasks into smaller, simpler tasks. HIPO and Warnier-Orr both did this, but with different graphical approaches in order to address the knotty “communicating with the user” problem.

I remember as an earnest young Arthur Andersen consultant conducting interminable “user reviews” of complex hierarchical decompositions of opaque utility company collection processes. The IT folk wanted to argue about the taxonomical ramifications of combining or splitting a level in the hierarchy. The user middle managers lounged around in their loud sport coats, checked their watches, and waited for the pain to be over. Their goal was to keep us out of their business, whatever that was. It certainly wasn’t collecting accounts.

In all of the design work that I did in the early years, no one EVER asked about change in requirements. The world was slower then, and the unexamined assumption was that with enough analysis we would “nail down” the system, it would come out of development fully formed, solve the business problem, job done. Change in the underlying business environment wasn’t considered.