"PLAN" is not a Four Letter Word (Part I)

Back in the early 80s, when corporations like IBM and Univac were mainframe giants, it took the typical systems team 3-5 years to produce a new compiler. It was during that time I took on a project to finish where some R&D left off. The goal: produce a compiler, assembler, and linkage editor for a family of computers in use in the world’s largest private computer network. This was critical because the only tool in existence was a non-relocatable assembler (a throwback to the 60s). Development builds of code were running for more than eight hours, and productivity was low. Introducing the notion of relocatable code would drop the time to minutes, allowing the development team to be more productive. More productivity would allow faster development of key network-related products and services.

The R&D phase had obtained the portable Pascal-P4 compiler and implemented it on a lab mainframe. With this proof of concept out of the way (elapsed time around four-to-six months), the real work could begin. The project tasks then included developing a code generator for the new computer family, a relocatable assembler, a linkage editor, and some supporting tools (macro generator, cross reference listing tool, etc.).

Planning for the project took three months. We felt this was a reasonable time to dedicate due to the perceived magnitude of the effort by industry standards. During planning, we kicked around different approaches, ran some estimates, but more importantly, developed an approach. Checking around with the 4,000 employees in the company, we found another project had developed a linkage editor that was close to what we needed -- the input and output formats were different. Still, we could salvage some of the processing code. We also recognized the key to efficient development was to define the object file format necessary for the assembler, code generator, and linkage editor to communicate. By the end of the third month, we defined that format and were ready to go.

One team member developed the assembler, one team member developed the code generator, and a third modified the linkage editor. Since the common file format was decided, it was easy for each team member to work independently. Two additional team members worked on the supporting tools and some miscellaneous routines to help out the three key developers. The result: by month nine, we were ready to test the system with live code. Just a little over a year total, the system was done and all the communications computers were running using the new code. The users loved the result!

Now you would think that with software of this magnitude, there would also be plenty of bugs. Not so, since during planning we identified the need for careful unit and integration testing. Only five bugs were uncovered during the first six months of operations and none after that. About a year later, we were asked to add another small feature. The system was productively in use for more than a dozen years. By then I was moving on to another company. I took a look at the execution counter associated with the file out of curiosity. The counter had rolled over and was sitting at over a million. We never would have achieved the completion of the project in one year and with high quality without that initial three months of planning.

Next week, in Part II, we’ll move forward a decade and see how good planning quickly made up for a mistake in planning.

[This article was originally published 19 January 2007]