Sunday, April 22, 2012

Replace Your Unique Web Addresses One-by-One, Just Like They Replace Unique Mailing Addresses in the Construction Industry

Many people in the software industry like to make an analogy between "building a house" and building an information system.

Fair enough, at first thought.

But, do you think construction workers ever tell other construction workers: "This is a lot like programming an information system...etc, etc".

Probably not.

Why? Because construction workers know that building a house is very little like programming information systems.

First of all, one is entirely physical and requires vast amounts of three-dimensional space, while the other, physically, is entirely based upon electronic states and fits inside of the space of a thimble. This is just a small example which could go on for pages and pages.

Yet, all is not lost in the construction analogy, especially if you think about rennovating a house, or better yet: a neighborhood or city improvement project, and compare that to the case of reengineering web-based, distributed information systems.

Neighborhoods, cities, and towns all have discrete, individual buildings. Each building has a Unique Mailing Address.

In a web system, each discrete feature, or "page" also has a a Unique Web Address, better known as a URL, or Uniform Resource Locator.

Suppose now a neighborhood is run down and an effort springs up to rebuild it.

What do you normally see happen?

1. A construction team studies the existing neighborhood, and carefully rebuilds an exact clone of it at a distance, but with more modern concrete, flooring, walls, nails, paint, and insulation, and then one day brings a giant bull dozer, knocks down all the houses, and uses giant helicopters to load every replacment house on top of the same old spot *ALL AT THE SAME MOMENT*?

2. One house or building, or a few depending upon how large the team is, gets rebuilt into something a new buyer wants to pay for and move into. Then, the next, and the next.

Of course, we all know it is the second scenario.

The first is simply fanciful and would be assinine. Of course, due to the physical, three-dimensional nature of construction it also is nearly impossible, at least for an entire street or town to be replaced in a single *MOMENT*.

Instead, house by house, surely enough, the Mailing Address that used to belong to a broken, dilapidated home, is replaced by brand new, valuable, livable homes.

It's a beautiful thing, as they say. Doing this, the team can "keep it moving", and by it, I mean cash flow, and I mean community and homeowner value.

Curiously, still today many software engineers and managers have failed to deeply analyze and ake to heart their favorite metaphor.

We see teams laboring under pressure filled "dead lines" to do a "big bang release in a single MOMENT" to replace a legacy system with hundreds of features or pages.

Or, if they have learned their lesson partially, they may run two systems in parallel, and slowly retire the old one while people are brought into the new one. While better, this option suffers from higher costs and lower return on investment as well as low user value.

This situation is beyond lunacy. In the former case, of single-MOMENT big-bang replacement it may even cross lunacy and enters professional irresponsibility and lack of due dilligence. At best, it showcases a sad lack of knowledge about web servers, lack of understanding about HTTP, lack of understanding about risk mitigation, and ultimately a lack of compassion for the customer and end users.

I blame not just engineers, but big contracting companies who perpetuate this situatiom on paying customers and governments who simply take their word for it that they cannot do it any faster, any better, or with more risk mitigation.

In a web system, as in a neighborhood or city, each feature, page, or controller, or script, or image has a Unique Web Address.

Each of these discrete units can, and should, be replaced in a careful, methodical, but ultimately FASTER, and return on investment increasing and risk reduing way.

Replace the parts at the end of your Unique Web Addresses one by one, just like they do in the construction industry when they replace the parts at the end of their Unique Mailing Addresses one by one.

I will be presenting a demo of how to do this with ASP.NET MVC being used to incrementally replace parts of a system built on classic ASP and ASP.NET WebForms on May 1 via