,

They Just Didn't Get It

Ivar wondered for a moment whether he should go along with the approach the programmers wanted. It would surely avoid a lot of hurt feelings. It would get the immediate work under way. It would get some kind of product out the door. In his mind, however, that was not enough. A switching system that resisted change–and change, he knew, was inevitable–would not meet the needs of telephone companies in one hundred countries. It would not accommodate the technical and legal changes of the next several decades. From the standpoint of Ericsson as a going enterprise, it would not carry the company through the competitive trials sure to come.
 
He had tried to explain the component-based approach, but he had not been successful. Most of the staff just couldn't get it. It was hard to understand why they didn’t get it. To him it was so obvious.  Lars-Olof Noren, called Lasse, Ivar's boss, was the only one that got the approach immediately. Of course, he, too, had had electromechanical experience.

What an awful idea!

“First of all, why do we need to have components?” the programmers asked. “What are these components? Why do we need to send messages between the components? How can a component send a message to another component? Why do we need to have interfaces between components? Why can’t a program access data of any other piece of data without having to send a message?”
 
In one particular meeting with the team–Lasse, Nils Lennmarker, Göran Hemdal, and some other core people–Göran asked why there had to be limitations such as a component cannot read other components’ data. "Why do we need to use a pre-specified interface? That is delimiting."
 
“In our approach, any piece of software, any program, can read any other guy’s data,” Göran pointed out. “That’s much more flexible."
 
The programmers joked a lot about the component approach. They ridiculed Ivar. One day some one drew a cartoon of a caricature labeled Ivar running around in a circle in a chicken yard. (In those days chickens still lived in a big yard enclosed in wire mesh, not a little box.) Above his head was a call-out saying "block, block, block, block, block.”[1]
 
Everyone felt that design with components was a step backwards. With the old approach they could have a one-to-one mapping between a function and a program, but with the new approach a component participated in several different functions.[2]  It was not a one-to-one mapping.
 
They regarded this participation in several functions as a strong argument against the proposal. Ivar saw it as exactly what the project wanted to achieve.  Data was localized to components and the program that manipulated the data was incorporated in the component.  Thus functions would cut through many components and a component would usually participate in realizing more than one function.
 
Another argument they used against it was that it felt like a lot of preliminary overhead compared to just getting the code out. Their preferred way of working was to start coding with a core of the system. They let the code grow from that core. However, they didn’t take into account in this core anything more than the very simplest features of what they had to do. Then, as soon as they added some of the complications they encountered to the growing system, they had to go back and change the core, sometimes at many places.  This way of working led to a never-ending process of changes. The reason, of course: architecture was missing. The so-called architectural design had never been done.
 
"We still hear this argument," Ivar notes. Even yet some people suggest that getting the code out is all that matters. That may be the case in small one-person projects where that one individual actually has the architecture in mind. It is certainly not the case in large projects where many developers, as well as clients and users, have to work together.
 
Thus, there were many arguments against the component proposal. They didn’t think it would work. No one liked it. It was just a stupid approach.
 
Ivar met with the leaders time after time. They even met weekends in an effort to figure out how to work together without fighting just in the coming week. Unhappily, the underlying schism continued to fester.

D–for Decision–day

During this long-running argument, Lasse had been supportive. However, he had been so busy getting another project failure taken care of that he had had almost no time to help out. After six months of seemingly endless discussions going nowhere, there was still no commitment on the part of Jacobson’s colleagues.
 
Lasse gathered the whole team of managers (some 13 in all) for a meeting in early June 1968. Jacobson was there, of course, but Lasse presented Ivar’s approach. He felt it was better for him to do so, since Ivar had been so involved in the months-long discussions. Lasse was a more neutral figure.
 
“I was most surprised by the reactions from the hardware designers, the ones I had expected clear support from.”
 
For example, Leif Svanberg was an experienced hardware designer who knew very well how to build hardware components.  He knew how important it was to deal with interfaces and to specify their behaviour without really looking at that point at how they would implemented. There are many different ways of realizing the behaviour of a specification. With electromechanics, a designer could obtain a certain behavior with ten relays or, after simplification, with five relays. Observers could evaluate the two solutions quite differently. Moreover, with electromechanical hardware, there had always been problems with interfaces. The number of available wires was always limited. So, in the software arena, even a hardware designer could have a hard time applying electromechanical experience to the new software discipline. Svanberg probably didn’t know what to think. He was obviously reluctant to get involved.
 
Another case in point was Noren’s boss, Per Carlström, who had worked with hardware design all his life. He became head of the organization because of the need for a mature person to work with the creative software people. He admitted, “I have always had problems with these hardware boxes with their limited numbers of wires in and out.” 
 
Designers had to use these wires, not in a simple way, each wire carrying one function, but in a complicated way, each wire carrying double or triple functionality. In effect, there was a publication protocol between any two boxes. That complicated the whole design. Thus, thinking about software, Per posed the rhetorical question, 
 
“Why do we need to complicate software with problems we have had in hardware for years?”
 
He was comparing the necessarily limited number of physical wires with the unlimited number of messages that software permitted. He did not grasp that the physical problem of accommodating wiring had no counterpart in the message-passing world of software. 
 
“Many of the people who came from the hardware side felt it was not really 'qualified' work.”  The individual who taught Ivar most of what he knew about hardware design, Jan-Erik Nordin, had this attitude. Ivar had worked in his group developing electromechanical switching systems.  One day Ivar told him he wanted to move to the younger software organisation. Nordin tried to persuade Ivar to stay in the older organization.  At that time the senior, very competent hardware developers viewed software development as something the drawing people could deal with. The hardware engineers believed they would never have to learn about software.
 
Ivar did not believe that.

Support or not?

After having heard everyone express his opinion, Lasse challenged the 13 top guys: “Do you want to support the component approach, or not?”
 
The only semblance of a positive response came again from Olof Ericsson who said simply, “I really don’t know.” The others offered variations on the same theme–that they did not believe it was the right approach. Three or four–among them Göran Hemdal and Oleg deBachtin–were more emphatic. If the company did go in Jacobson’s direction, it was headed straight to hell.
 
So, the consensus of the managers was that this very dramatic decision could result in  catastrophe to L.M. Ericsson. “I didn’t say anything,” Jacobson says. “What I wanted was clear.”   

The decision

The meeting had taken a couple of hours and Lasse closed it by saying,
 
“Well, there is no other way to do it and what I have just described is the way we’re going to do it.  I can understand that not all of you want to do it this way. Those of you who don’t like it, you’re welcome, and I’ll give you new jobs.” 

[1] Something like "block, block" or "cluck, cluck" is the noise that chickens make when the housewife enters the yard with axe in hand to select a chicken for dinner.
[2] Those familiar with the concept of "use case" can think of "function" as a use case.