"Given the undeniable trend towards all-encompassing change in software development, the case can be made that general purpose software is doomed to always be unreliable and buggy."




"Is this some sort of collective insanity that has somehow woven its way into our society?"

12.8.08

 

Atomic powered Project Integrity Management

When creating a system for keeping up with massive ongoing change, there are many things to consider and it is easy to become bogged down in the details of it all. This may explain why so few projects ever follow through with their configuration management plans. While it is obvious to many people involved with a project that some kind of change control and configuration structure is needed, it is not so obvious what that structure should look like.

As a software developer, I find that in situations where the problem I am solving is extremely complex it helps to approach it from different angles. Most things that are complicated at one level are fairly simple at another level. Biology and physics are chock full of great examples but the most readily understood one may be the atom. In the universe we occupy, there are untold levels of complexity and variation. Plants represent a different sort of complexity than mammals, and geographic formations and planetary orbits represent still an entirely different set. But when the problem is viewed from a lower level, similarities emerge that are not initially obvious. For example, all living things are made up of cells and require energy. They also all have a typical lifecycle. At an even lower level, the plants around us, the air we breathe, and the ground we walk on all have things in common, most notably that they are made of individual atoms of a finite number of elements.





That is great from a conceptual standpoint, but it doesn't do much for solving the problems faced with ever-changing projects much. It is too abstract to be useful in this situation, but it does illustrate a very useful technique for getting to the heart of a problem. What we need is an example that has already been figured out, tested and implemented to base our thinking on. Ideally it will be something less abstract, more physical and easier to picture. I think I have just the example needed.

Years ago transportation of goods was a very manual process. Farmers or shoemakers would gather their goods and haul them to a port where they were placed in wooden crates of various sizes then loaded by hand or with hoists onto waiting cargo ships. Those crates were then stacked as securely as possible in the holds of the ship where they were later hand-unpacked at the destination. Crates were then transferred to waiting trucks and boxcars where they were moved to their final destination where they were once again hand unloaded.

This was a process full of inefficiencies. In 1956 an American trucking firm owner named Malcom McLean purchased a used tanker ship and converted it to carry aluminum truck bodies in frames on its deck and started the company that would soon be known worldwide as Sea-Land. With the success of this idea came a revolution in cargo transportation. Seeing the need to standardize all containers so that they could be stacked securely and transferred from one mode of transportation to another, the standard shipping container was born. Today nearly all goods shipped across the oceans are packed in these standard containers. Now whether a container is filled with tomatoes, shoes, televisions, or computers, it can be handled and managed in exactly the same way with exactly the same equipment. Specialized trailers and rail cars allow containers to be transferred directly from the cargo hold or deck of a ship to an eighteen wheeler or rail car without ever being touched with human hands.

But packing everything in container only solves part of the problem. The real complexity of shipping still remains. Now that all containers look identical and could contain anything, a system is needed to identify and track the containers wherever they go. Some system must ensure that a container of oranges makes it to the grocery warehouse in Little Rock, AR on time.

The solution to this problem is the assignment of a unique identifier to each and every shipping container. These numbers are painted on the side and are used extensively to track where the container is going and where it has been. The container ID gives the ability to pull any amount of information about a container from any databases that use the identifier. By creating unique identifiers and maintaining databases of activities based on that ID, the problem of identifying and controlling each one is greatly simplified.


A typical shipping container



A cargo ship loaded with shipping containers



Shipping containers being unloaded.

So to summarize, the solution to the extreme complexity of packing, transporting, and tracking extremely variable products has been neatly solved by creating a standard package that all shipments are packed inside of. To facilitate tracking and routing, a unique number is assigned to each package. The combination of these two concepts, standard packaging and unique identification provide a powerful example of how extremely complex problems can be greatly simplified by abstraction. No matter what a container holds or where it is going, as far as the ship's captain, the crane operator, the railroad conductor, or the truck driver is concerned, it is a container with a certain destination.

Can you see where this example would be applicable to tracking components of a project?