,

The New Idea

Back then, at the time of this controversy within Ericsson, people involved in software development thought in terms of separating the data that needed to be in the system from the programs that were to manipulate that data. They considered this technique to be very flexible. They felt that they could introduce new data–in the data structure–or new programs–in the program structure–very easily. Within this pattern, a new program could interact freely with any existing program. A new program could access old data to do some new things. There seemed to be no limitations on what could be done because everything could access everything else.
 
That very freedom was the Achilles heel of the program-data approach. For example, when a programmer brought in a new program that was to manipulate old data, he/she usually needed to make some changes in how the old data had been structured. He had to find out which old programs used the old data. The old programs could be quite numerous and some of them might not work well with the new change in the data representation. In other words, a programmer contemplating some change had to explore the old code extensively. The old code was often difficult to understand; with added changes it became very difficult to understand. In fact, it often became a mess. The outcome: change was very difficult to manage.
 
This old technique has many names: the function-data approach, the functional decomposition technique, and still others. To implement this way of looking at software development, software people developed many methods. This technique, dating back to the early days of software development, is still used by most software organizations. Unfortunately, it creates many problems. One of them was the Year 2000 problem, the still-remembered "Millennium Bug." 

Function-data led to Y2K problem

Storing the date in the data structure and the programs that used the date in the program structure was an underlying reason for the Year 2000 problem. In a bank application, for instance, this approach kept the date (for instance dd-mm-yyyy) separate from the many programs that needed the date to perform their own function. That function might be to calculate interest, determine the length of time an account had been in use, or many hundreds of other applications. The need to use the date often turned up several times in many programs.   
 
Unfortunately, the software developers of the time–still far from the end of the 20th century–had no consistent standard for writing the date. People were accustomed to writing only the last two digits of the date, such as 77 for 1977. Developers had been born in the 20th century, had never known another century, and the "19" seemed quite superfluous. Storage was quite expensive. Programmers tried to reduce cost by abbreviating data, and dropping the "19" contributed to that goal (dd-mm-yy).  On top of this, they were trying to optimize for all kinds of reasons. Programmers invented their own data structure to represent dates.  That was the root of the Y2K problem.
 
As the end of the 19xx's approached, of course, those first two digits assumed critical importance. Correcting the problem became imperative. The cost became enormous. That cost would have been much less with the new approach, component-based development, as we describe in a later chapter.

Old approach did not fit Ericsson's needs

Jacobson realized that if the Ericsson team did not develop the new system in a different way, the system would encounter "zillions" of problems (of which Y2K is an example). In telecommunications, as in most other software, the only thing that is really constant is change. The Ericsson system had to accommodate the changes that more than one hundred customer countries would impose; it had to accept the legal, administrative, and technical changes that coming decades would surely demand. If the system was to endure during the time duration expected in the telecom world, it could not rest on the old model separating programs from data.
 
Even today, as these words are being written, the majority of all new software products are still being built according to the principles underlying the separate program-data model. This–the atrocious development model–is the really big bug the software industry still has to crack. Unlike Y2K, this big, bad bug has no absolute deadline to spur action. The result is almost certain to be many years of pain ahead. Governments will pay the price in the form of taxes higher than they could otherwise be. Industry will pay the price in the form of sales lost to fresher companies, more alert to effective development practices.

The lesson of hardware: components

At this point Jacobson's background differed from that of his software colleagues. He had three years of experience in developing systems implemented with hardware. Their experience was in software. His experience with electromechanical techniques, they considered outdated. They felt and said, quite strenuously, that there was “nothing to be learned from the old way of doing things." They thought that applying these old ideas from the electromechanical age would only serve to limit their thinking. They sought a way 180 degrees in the opposite direction.
 
On the contrary, Jacobson found that the electromechanical experience had taught him a lot about how to think and build in modules. It had taught him that modules could be readily changed as circumstances dictated. In fact, Ericsson had had generations of experience in doing just that. The approach he was proposing for software development meant that, at first, developers should not really care about what was program and what was data. That separation had to come much later. It was too low level at the initial stage of system structuring.

Applying the component concept to software

Instead of the view based on program-data held by the programmers, Jacobson viewed the system initially as being composed of interconnected components. At that time, Ericsson used the term “block.” The system as a whole is composed of connected components, and these components have very well defined interfaces to the outside world, that is, to one another. Inside the component, there could be basically anything, as long as it met the interface, that is as long as the component provided and used interfaces that were defined.
 
So, inside a component, if you used assembler or a (high-level) programming language, if you used a lot of data, if you had a lot of programs or even a piece of special hardware, it didn’t matter, as long as you developed the component to meet the interface.
 
When a subscriber lifts a phone, one of the components in the telephone system detects it. That component sends a message (called a “signal” in the electromechanical period) to another component. On reception of a message a component does some internal computation and may send a message to a third component, which may return a message to the second component, and so on. This was how a telephone call was executed by the components in the electromechanical age. It was how Ivar proposed to implement a telephone call in the computer age–namely, in comparable components in the software within the computer-based system. 
 
Ivar's colleagues seemed to regard the component concept as on the one hand unnecessary and old-fashioned, on the other hand unique and revolutionary. "That has never stopped surprising me from the day in the fall of 1967 when I first presented it up to the present day," Ivar exclaims.  "It was not unique; it had a long history within Ericsson. I suppose it might have seemed revolutionary to the programmers schooled in the program-data breakdown."
 
During the years since 1967 Ivar has described the component approach to lots of friends and people in other lines of business who did not know anything about software. They have been able to understand it without any trouble. Then they would almost always ask, "Can there actually be any other way to do it?"
 
 “Well, I had to admit that there was another way, the way the programmers wanted to go," Ivar explained, but then he would add, "To describe the other way to someone who doesn’t understand software is close to impossible.”
 
What Ivar described that weekend in the fall of 1967 was a methodology of how to do component-based development. What is a component, how do components interact to make up a telephone call or any other functions, how do you represent a component?  His long weekend resulted in a document with a couple of block diagrams showing the components of the system and their interconnections. (Today in the Unified Modeling Language those block diagrams would be called a class diagram.).


Recovering the 1967 document

Fortunately, Ivar was able to recover a copy of that document from the archives deep in the cellars at Ericsson in 1978.  It had a note attached to it: “Must not be copied” signed by Björn Svedberg, then the third-level manager above Ivar, later the CEO of Ericsson.  He must have written this note in 1969 when the paper still was quite controversial and component-based development was still to be proven in practice. 
 
He probably prohibited copying for good reasons. For instance, the paper had not been updated. That original version did not include the lessons learned in implementing the component concept. Moreover, it described a prospective Ericsson competitive advantage, best kept within the company.
 
Still, to Ivar it was quite strange to see the original paper, a paper that initiated a change in software development practices previously unheard of, still lying unsung in the dead archives.