Configuration Management? What's that?

All this functionality going into the system was great. The controllers were getting what they needed, but what patches were out there, and which facility had which patches? There was no overall plan to document the software modifications. The same patch could have more than one implementation. It took years to reign in the coyboys and impose some managment of software. We cowboys were learning some computer science. We were ready to clean things up. This situation existed because we innocently didn't have the background in the science of computers. Computer science itself is more of an engineering discipline. Controllers or ex-controllers for the most part did not know about the need to document and manage these things from a higher level. Each of us probably looked at these things on a local level and didn't realize that there was a bigger picture. Controllers because of the nature of the Air Traffic World of rapid decision making, where one makes descisions in milliseconds and never has the luxury to do any long term planning, where everything was "shoot from the hips", wrote programs in the same way. It was like "Oh, I can write a program to fix that problem", and then wrote that program, tested it locally, implemented it, with minimum of paperwork involved, because programs were written just like airplanes were vectored through the airspace. There is no time to submit paperwork or do any long term planning when you are controlling a bunch of airplanes. You just do what is necessary to keep things safe, and you do it quickly. That is the culture the we came from, and didn't know that some things do not need to be "spur of the moment".

In the wild-west days of software freedom, some very innovative software mods were developed by these "cowboys" In harmony with the Connecticut Light and Power's research ex-controllers understand the nuances and vagaries of Air Traffic Control. But most of us didn't understand anything about Configuration Management. Even though the cowboys wrote some tight code, as far as the whole system was concerned, with the plethora of program modifications, from the point of view of a System Architech it was spagetti

Continue to ATC Automation part 4 "Scatter - Apocalypse Now" Submarine dive horn in a Radar Approach Control? Scatter...?
Alone in a sea of non-programmers
Home ATC Automation Part 1 ATC Automation Part 2 ATC Automation Part 3 Scatter Scatter Part 4 Radar Handoff - part 5 The Tower Controller