,

An Unlikely Assignment

It was 1967, in the summertime. After five years with Ericsson, Ivar had just moved to a new department. This department was to develop a new generation of telecommunications systems using an exciting new technology.  Essentially, this new technology was computer based instead of electromechanical.  It meant that the switch would be controlled by a computer driven by software. 
 
Dramatic changes lay waiting in the wings. Of one change, the cast of characters, the engineers in the department, was well aware. That was the software control of telephone switching stations. Of the other change, the method of developing that software, no one was yet aware. Yet it, too, would have an impact felt ’round the world. It would be a new way forward in computer science accepted in later years the standard practice. Moreover, this new way would become the basis for the greatest commercial success in the history of Sweden.
 
Ivar had been in the new department only a month when he was offered the position of project manager of the first system to embody this new approach, the AKE switching product. The position was to change his life and that of many of the people around him, not always for the better.
 
"There is no safety in change," he realized later, "and change was what was at hand."
 
Why Jacobson for this critical position? Why a young engineer only 28 years old at the time? Why an engineer with no experience in software?
 
“Well, at that time, I really didn’t think about it at all," Ivar reflects today. "Like many young men, I might have thought, 'Of course, me.'  When you are 28, you think you can do anything. There were absolutely no limits."
 
Looking back, he thinks the managers might have had a reason. "They realized that I didn't know much about software, so they figured I couldn’t create a lot of problems. It was logical to assume that the experienced programmers already on the project would guide me.”
 
Over the next couple of months, Jacobson spent all day working with the key people--the leaders of the individual teams and the specialists.  All together the project numbered about 75 people. All of them were engineers. Most of them were programmers. In those days programmers were almost like artists. From their perspective, programming was the most exciting thing one could do. It was the hottest of the hot. Their counterpart toward the end of the century would have been the creative designers of Websites.
 
Later, when the new approach to software development pioneered by the AKE project took hold, almost no one at Ericsson was titled a programmer any more. They all became "developers." No longer would they view themselves as "artists." They would think of themselves as doing a job in product development, similar to the way products had been developed for years. This way was very different from the way people in the world outside of Ericsson still treated software development.  There, software people were still called programmers. There, the flavor of artistry persisted.
 
These early software technocrats created their own words. They seemed to be making every effort to originate words that were different, instead of taking advantage of the terminology long employed by the older disciplines. That made it almost impossible for someone outside each petty realm to understand what they meant. This play with words may have been nothing more than an attempt to create an atmosphere of elitism.
 
“It was part of the whole game,” Jacobson believes. “You wanted to be different and that made programmers different.”
 
In some areas of software development, the new-word plague still holds sway. People are inventing new words that sound hefty--words that only those who have spent time learning them can use. The syndrome still bedevils Web design.
 
When the AKE project was getting under way, there was very little documentation.  Laptops or personal computers were not even a glint in someone’s eye. Notes were written out by hand on paper, then if important transcribed by a secretary. In fact, there were not even copying machines.
 
The literature in software development was very poor; there was no book that explained it all.   There were no courses, or very few courses in the subject matter, either. Jacobson had to teach himself by reading and re-reading product documentation until he understood what it meant. That is how he spent his evenings and weekends--in the attempt to educate himself.  He would review what scant material was available, make copious lists of queries, and ask people questions about the material, seeking explanations. “What I learnt about software came from studying what we were doing,” he remembers. This effort took him several months.
 
By day, of course, he was managing the project or, at least, administering it. For example, he attempted to put his teams on a schedule and to get them to understand what a schedule meant. After three months, he came to a startling realization:
 
The project was not going to get where it was supposed to get. It could never
accomplish its mission unless it totally changed its way of doing things.
 
With the assignment, Ivar had received a quite detailed specification of the product to be.
Explicitly spelled out was the expectation that the system was to be marketed all over the world as, indeed, Ericsson's existing systems already were. The AKE was to be easily adaptable, with little additional work, to the differing requirements of each country.
 
That was how Ericsson had always worked with its projects based on electromechanical technology. Its home market, Sweden, was small. To be a successful player on the world stage, its products had to be easily tailorable to the different circumstances encountered in each country. It was borne in upon Ivar as he passed the three-month point that software development, as it was then being practiced, would miserably fail this criterion.
 
"Even today year 2001, the software industry in general does not know, how to develop software that it can specialize easily for customers with slightly different requirements," Ivar posits. "In the 1960s we talked about adapting or tailoring software to the market. What was meant we now mean by developing software 'for reuse.' Development for reuse is still quite hard. Only a small percentage of our whole software population has any good technology for doing that.”
 
The technology that Ericsson's engineers were employing was, in a way, not very different from the way that most people still are developing software. Ivar estimates that 75, maybe 80, percent of all software development is in principle still done the way Ericsson was doing it then.
 
So, the task posed by the AKE project was impossible using the technology of the period, both for Ivar as the project manager and for the company as a whole. What was this existing technology? Basically, it separated the database from the program that manipulated it.  This separation was not just something that was built into the computer architecture, it was also something that was maintained in the design and implementation stages of software development.  During these stages different people were responsible for what would end up as program and what would end up in data. 
 
In fact, even today, separating data and program is how most software is being developed. Back in the 1960s people thought they had state-of-the-art technology doing it this way.  For instance, Bell Laboratories did it this way.  Bell Labs was very much a forerunner for how to develop software for telecommunications. IBM did it this way. Everyone did it this way. So there was nothing really unique about what the AKE project was doing.  It was not wrong. No one would be blamed for developing software this way. It was, from a manager’s point of view, the safe way to take. To continue to take it was the conventional thing to do.
 
To Ivar’s mind, however, it was wrong. His thoughts marched to a different drummer, and that is where the troubles began. How sad to see heroes fall.
 
“We had heroes at Ericsson," Ivar continued. "I remember, in particular, Göran Hemdal, who was called ‘Father Göran’. He was a genius, or as close to genius as anyone can possibly come. The man knew the value of π to 300 decimal places.  I actually checked it one day. I had a list of them and he called them off correctly. Just to have that kind of interest is quite unique."
 
More significant for the work at hand, he had an incredible capacity to model things. He could describe a huge system on his own, using flowcharts, page after page after page. He could do a job in a weekend that normally would take someone else half a year.  The problem was that no one else would know what he had been doing and be able to maintain it. The approach that a genius could use was not one available to engineers of normal attainments.
 
Göran had been with Ericsson for some five years before Ivar came along to the project. It was Göran who had developed the way the company was doing software. Göran was considered the leader of the new computer-based technology, definitely the guru. Nevertheless, as Ivar began to ponder the "impossible" problem he faced, he began to feel that Hemdal was “a little too smart to develop methodologies, because he would develop methodology for himself, and not for ordinary people.” Still, confident in their long friendship, Ivar did not foresee the stormy times that lay ahead for their friendship. He did not expect the conceptual differences to tear their relationship apart. Neither did Göran, he learned much later.
 
After three months of trying to understand the development approach the team was using and thinking about how that approach would work when the software had to be changed, Ivar could see “no way we could be able to manage it.” So he went to his manager and told him, “This approach will never, ever result in an product. We are developing something we will never be able to adapt to all these customers or to change later.”
 
“Well, Ivar,” the manager responded, “if you are telling me that this critical project will not result in a product, then you must know how we should do it instead.”
 
With all of the self-confidence a 28-year-old can muster, he assured the manager, Lasse (Lasse was his nickname, his real name was Lars-Olof Noren), he was quite certain he did. He went even further out on a limb that Friday in 1967 by not only stepping up to the plate, in baseball parlance, but also by agreeing to proffer his proposal at the start of the very next work week, on Monday morning. Locking himself in a room over the weekend, Jacobson pored over the task hour after hour after hour. His wife and his children were left to their own devices as he slaved over the challenge.
 
All day and into the nights, Ivar wrote his way through the weekend. Monday morning, he turned his handwritten papers over to his secretary for transcription. Exhausted, he was, nevertheless, “Very excited about the result. I knew, at that time, that we were changing the approach for how software development should be done.”
 
That morning, Jacobson described the approach for Lasse, his boss, who said simply, “I like it.” Lasse passed it along to his manager, who told his manager that Jacobson had come up with a new approach to developing software for their system.
 
The third-level manager asked to meet Jacobson. Up until that point, Jacobson had heard of the man, but had never met nor even seen him. “He was like a god,” Ivar recalls, “and he wanted to meet me!” The manager wanted to understand what Ivar was proposing. Years later, he told Ivar he had not understood the document at all. At the time, however he gave Jacobson the go-ahead to run with it.
 
“So I felt we were on track,” Ivar said, shaking his head. “Very naïve, very naïve.” It seemed, at the time, that it was just a simple matter of implementing the plan within the organization. He sought the blessings of his colleagues. Perhaps, at first, the full sweep of the new approach he did not make clear. Perhaps they did not understand that it would have a severe impact on everything they did. Perhaps they thought it was just a way to document what they were doing anyway. Once they grasped the reality that it would control the whole way they developed software, their discomfiture mounted. Göran’s life became “miserable,” Ivar learned later.

top