How I landed my second of many projects.
Project #2
After my re-start in October 1971, I continued my university education, the successful finish of which lay in winning my diploma. Here is how it happened:
When I was in the then fourth semester in the summer of 1973, I noticed that it was about time to sit my interim diploma exams. And I noticed that, indeed, there was quite a knowledge gap.
Consequently, weeks of learning lay ahead. The weeks before the four oral examinations would be stressful. I fell victim to knowledge bulimia, a sickness widely spreading these days and actually an epidemic in all the school and university systems I know. After having passed the interim diploma as required (surprisingly even with quite a fair grade; “good”), I was rather worn-out and had to give myself some rest.
Resting was exceptionally great fun while breathing computer air at Siemens. They truly had a lot of hardware: large-capacity computers with BS2000 and BS1000, process computers, office systems, network computers and much more. I was truly over the top. At the TH – which was now called TU, because, after all, a university is something better than a college – the computing times allocated to students was rather scarce. Consequently, you seldom saw me there.
As a logical consequence, I spent more time at Siemens during the following four semesters than at the not very humane (and probably even then asbestos contaminated rooms) of the new southern TUM informatics building. Incidentally, said southern building was torn down several years ago. Just imagine that the building where I studied and which had been built more than 20 years after I was born was outlived by me. Now isn’t that somewhat strange? The old TH building is still prospering.
It was my good luck that my major topic, mathematics, could easily be studied out of books. They are a good substitute for attending and listening to lectures. After eight semesters, I noticed that there was a diploma thesis to be written before admission to the final exams. I found a professor (Dr. Werner Heise) – regardless of having been the youngest mathematics professor of all times at the TUM, he unfortunately died a few years ago – who was willing to hand me a really exciting combinatorics topic for said diploma thesis (it was about the assumption by George Polya which, however, had not yet been proved – which is how the theorem by Dürre came to be).
It was not easy, but it went well and was a truly great experience for me. I also enjoyed actually meeting Mr. Polya from Hungary on a combinatorics congress in Berlin. The trip to Berlin was especially fascinating because at the time Berlin was still a wonderful island in the middle of enemy country.
After the diploma thesis, the final exams lay looming – and again I fell victim to knowledge bulimia. It was even worse than before the interim diploma. But, again, the knowledge bulimia worked well. There came a day when, although totally exhausted, a very happy me held his diploma document in his hand. To be sure, I did not know if that was something to be proud of or not. But I was immensely happy to have finished the sad chapter “university”.
I was not in the mood to write dozens of applications or similar things. A journey around the world or even a vacation were also out of the question, and so I tried to find a job. I applied at Softlab. I found this company really great, because at Siemens, I had once read the hectography of a book by Peter Schnupp (structured programming) and I found said book a beacon in the darkness. And Peter Schnupp, whom I later met and who became a much-loved friend of mine, was one of the Softlab founders (along with the colleagues Neugebauer and Heldmann).
Consequently, I sent my first (four years later, there was a second one) application to Softlab. It seems, however, that at the time Softlab was undergoing minor crisis phase, which is why they sent me a very polite letter of refusal. It said that they actually were quite interested in me, but currently had no tasks appropriate for my skills. They also asked me to try again next year.
Naturally, that was not much help to me. But as matters developed, it turned out that, more than four years later, I landed with Softlab anyway – but that is another story.
“After finishing your university education, you have to work!” – that is what the bourgeois part of my super-ego told me. So I took the same documents I had sent to Softlab and used them to apply for a job at Siemens AG. I was optimistic, because, after all, they already knew me. And, yes, they took me – and they also had a real project waiting for me. It was part of a bigger project, which again was part of a really huge project.
I ended up at UB D WS ST DF 131, which is short for the department data processing, laboratory for systems, system technology, data transfer, 1st company, 3rd train, 1st battalion. The last three terms are my personal interpretation of 131. After all, the founder of the enterprise took the Reichswehr as a model for the organization of his company
The entire DF (which means an entire company of the Siemens army) worked on a hardware and operating system for realizing the data networks called TRANSDATA. Incidentally, I think it is another disgrace for the German IT that this term cannot be found in Wikipedia (I wanted to put a link right here). After all, this was the only and technologically superior competitor of “SNA“ (System Network Architecture) by IBM, who were our biggest and then perhaps only competition.
The Transdata software was called PDN (programmable data network technology) and we generated operating systems necessary for the data station computers, the network node computers and the mainframe model computers. Those two years were probably the most exciting years of my entire professional career. I could easily write several books about the time.
On this picture, you see a Siemens & Halske repair shop in the rear building at Schöneberger Straße, Berlin, on October, 19th, 1846 (Source: Wikipedia)
The official term for our facility was: laboratory. My group, the 131st of DF, developed software and was responsible for APS (short for user’s programming language). The language was supposed to make the “stupid” connecting computes do the (pre) processing as early as at the fringes of the network, for instance when it came to collecting data for a business process in the user’s dialogue. Also, it had a controlling and “intelligent routing” purpose.
Within DF, there were a number of teams, all of them developing new things. Because a computer network needs a lot of modules and, considering what times we are talking, it was rather complex (or highly complicated). And the team cooperated on a high intensity level.
Together with the customers and the partners of our FBZ (technological counselling centres at Siemens AG), we made Transdata the basis for the new big IT projects. And it all happened in a very agile, open and slim way. The minutes of the coordination meetings with the big projects and the technological counselling centres were our specification sheets. There was also a management, but their primary task was to see to it that all humans were happy. And to protect the teams from the Siemens management.
We worked in an enclave, in the Ortenburgstr. It was one of the many Siemens locations outside Hofmannstr. There was an actual bakery on the ground floor, which in itself made the location attractive. No barracks and instead tasty pretzels and rolls.
Some way or other, we all at DF were a good team and made the dice roll. We were all engineers and developed technology for real projects. And Transdata became a success. It made me proud to work on systems that often ran in important and revolutionary projects.
At the time, my job description was:
Synchronously programming on three versions. Version A (for example 4.0), which currently was on the market, was maintenance I had to do. This was about correcting errors and communication with users. For the next version, I developed the functionality as had been agreed upon and decided (version B, aka 4.1). And then, I had to plan version C – which would be 5.0 in our example – with the project partners.
Thus, the time we invested into the future was quite considerable. Because the market was demanding and very dynamical, the competitors were quick and consequently the speed had to be high.
On top of programming three versions simultaneously, I had more tasks, too. Of course, I wrote the manual for our programming language myself. I had to do the technological supervising of our large-scale projects and teach courses for the system engineers who used our system.
On top of this, I also organized the test of our new functions with our pilot users and wrote the product flyers for our marketing. In those days, new employees were recruited all the time. After half a year, I actually was an “oldie” at Siemens because of all those “newbies”. And we also had to continue our education – which was mainly done by reading the ACM or IEEE lecture notes.
As a side-line, we organized a coffee machine and a fridge for our office – which caused quite an earthquake with the Siemens administration. A coffee machine in a Siemens office – that was against all regulations (regardless of the fact that such a machine, allegedly, could be bought at a discount by the employees at “our” shop). But we managed even that.
And then the sad times started. Management grew more and more powerful. They introduced division of labour. It was some kind of development Taylorism in the laboratory. In addition, the administrative processes grew more and more time-consuming. That was in the second half of the 1970ies. We had to kiss our laboratory idyll good-bye.
First they introduced the manual editorial office. We had to teach persons who had not the slightest idea of how IT worked what needed to be written in a programming manual. Then came quality management. Those were people who had to have tested our software before said software was prototypically used by our customers. Except they had no clue about software and testing same.
Then they introduced product management and requirement engineering. All of a sudden, there were mile-stones, such as A20, A30, B20 … B50. The waterfall model came. Even the termination of the product was defined with enormous precision. That was T50 if I remember correctly. It was called project phase model. And we were no longer allowed to do any programming. Instead, we had to think about the level of maturity our work had now achieved.
They started the budget concept and expected us to make (guess) predictions about the expected cost for all discussed functions. Unfortunately, most of the new functions were very innovative and involved a high degree of creative research. Thus, predicting the expected cost soon became more time-consuming than the actual programming. Except that we were no longer permitted to do any programming, anyway, because in order to decide if there was to be any programming, you first needed a tested and approved cost estimation.
And thus it happened that what formerly we could discuss directly and decide with the customers and the FBZ on one afternoon now was discussed at greater and greater length. Weeks turned into months. Strange decisions were the often absurd results. Again, you had to discuss them at great length – or else you were secretly building u-boats. Which is not really without danger in a well-controlled concern. But then, there is nothing you would not do for a successful project, is there?
Additionally, they decreed working times that made it clear to us all that we were not permitted to work as much as the project would have required. As a logical consequence, they later installed time stamp machines in Neuperlach for the engineers. And if you were caught continuing with your work after you had stamped out, you had to be reprimanded by works committee decree.
Even taking work home got harder and harder, because plant protection had come up with a random generator at the company portals. If the generator sounded, you were controlled (shaken down) and it was absolutely forbidden to take documents home with you.
Thus, it got worse and worse. New sessions with three or four letter abbreviations were introduced (I forgot the abbreviations). Persons from new departments you never knew could exist suddenly sat around the table. “Cross section responsible persons” demonstrated how important they were. People who had no inkling of the market and the technology but were great with common phraseology were more and more powerful in product development. This cost a lot of money and much of what was decided was just nonsense which, naturally, never materialized. If decisions were made at all. All these measures caused helplessness and frustration.
In a nutshell – it was about time to leave. Consequently, I moved – inside Siemens AG – to a department where actual projects were still realized (UB D V S 3 – company sector data processing, sales and special projects, department3). After all, you were still supposed to work on true projects and remained free from bureaucracy and management mania – at least for a short time.
I had a nice offer, because at UB D V S 3, (not only) one project that was particularly important for the leadership was suffering from a crisis. And said project was behind schedule by quite a bit. It was called DISPOL and they had to develop it for the Bavarian Government. The task was to make the police fax machines (communication), the data storage cupboard (database and archive) and the typewriter (document processing) obsolete by introducing IT equipment.
This was the project during which I, for the first time in my life, met a true project manager … He was supposed to save the project – and that was my job, too. Together, we actually managed it. Because he left the technology experts to do their thing and did not interfere. But I am not yet going to tell you more about it here, because that is the third story from my series “vintage project management as told at the Berlin PM Camp”.
RMD
(Translated by EG)
P.S.
Today, you have personal managers and service managers. A short time ago, I read “coaching manager” on a BVS.de visiting card. Human resource is about BGM (company health management). The enterprises have their knowledge management and there are certified knowledge managers. If all this does not help, you install an innovation manager and if you need even more than that, you still have the change manager. What a brave new world …
P.S.1
Here a diagramm of Siemens – is it not a wonderful example for vintage project management? Andreas Weber has sent it to me – Thanks – dear Andi!
Loading ...