CLOU/HIT at InterFace Connection
Or:
How Wolf and I eventually ended up doing it ourselves.
During the Berlin PM Camp, I related the stories of four projects from my vintage time. They were all very important to me. And I told you here that I was going to describe them all in the IF blog.
Projekt 4
Now comes the story of my fourth project:
Even before 1983, I was fed up with working for others. At the time, I was still a Softlab employee. This is where I learned to extend my one-sided competence – with the exception of a little SNA (IBM), it was mostly Siemens technology – and learn more IBM technologies. In particular, however, I was able to learn about the different systems of the “intermediate data technology”.
I am talking machines which, dependent on their storage unit, consisted of two to three parts and had the size of Bosch refrigerators. That means they were a lot smaller and also a lot simpler than mainframe. At the time, those were especially fashionable. Consequently, there was an enormous amount of European and non-European competition with differing and often very proprietorial technology. Kienzle and Nixdorf were also among those aspiring MDT enterprises. And in those days, even in a city like Munich, the same software was developed synchronously in different enterprises for different technologies.
I am sure that Softlab was one of the most innovative German “software houses”. They, too, had a proprietorial system, the famous PET-Maestro. For me, this was the first system without the permanent frustration of data loss, because the Pet-Maestro already worked in symbols – and every symbol was immediately transferred to the hard drive. Consequently, you had a current warm start with every reset – and nothing was lost! It was such a relief to finally no longer have to fear data loss at all time when working, for example, with EDT or EDOR.
On other fronts, I also learned a lot of new things at Softlab. This is particularly true for the business sector: how to formulate an offer so that it contains the least possible risk, how to talk with the VB-s of the big enterprises (Bull, ICL, IBM, Nixdorf, Siemens – even at that time, nothing was going without the big ones), or how to write studies.
This is how I became a paper tiger (totally unrelated to paper tiger, the famous Chinese theatre movement). And in those days, it was (still) true that you got better pay per hour as a paper tiger than as a programmer. Thus equipped, I wanted to do it myself. Yet I did not dare to start all alone. So I went in search of a partner. I looked for and identified persons in my vicinity who I found nice and competent. And who perhaps also wanted to found a company. There were quite a few. But again and again, nothing came of it.
Until Wolf (Geldmacher) came. Wolf was considerably younger than I. Technologically, he was super. And our view of things was similar. Meaning that our values, expectations, interests and needs complemented each other. I was more the old style programmer – and Wolf had the knowledge about everything that was modern and new in IT. Also, Wolf knew absolutely no compromises when it came to quality. And if anybody had common sense, then it was Wolf. And I guess those are the most important factors: competence, common sense, quality awareness. Then you only need to be a nice guy…
Consequently, we founded the short version of InterFace Connection. We inherited the InterFace from Peter Schnupp, the “Connection” was our own contribution. That is what we wanted to be together with our employees: a “connection” that sticks together and later shares its success. We founded the enterprise in 1983 and started business on April, 1st, 1984.
But then, the enterprise is not the project I want to talk about. The project was about developing a product. And there were two reasons why Wolf and I wanted to have a product: firstly, we were convinced that a product would be something to be proud of. It creates an identity. Secondly, a product is easier to scale than a service.
Besides, in our eyes, the then well-established concept of “body leasing” did not have a future. Basically, we still believed in the law and as founders, it was pretty obvious to us that the common form of body leasing was exactly what, according to the AÜG, was simply illegal.
It did not take us long to become quite convinced that, in those days, Unix was the best basis for future products. Also, we agreed without hesitation that, basically, everything you needed for using computers was still missing in Unix. And in particular, we saw that a text system was sadly missing. And that the first thing you would have to develop rather quickly on Unix with its new data displays (in raw or cooked mode) and especially with the language c was a comfortable typewriter.
Since we had a huge amount of respect for the production and successful marketing of a product, we started the development of the product in cooperation with InterFace Computer. It did not take long before we had a small success in the SINIX (the Siemens Unix) environment. Consequently, the development of the product was moved to us and the InterFace Computer was put in charge of the ports and the sales on the “remaining market”.
And in no time, we also had a two-digit number of team members, all of them very young. In general, they were students. They had to have programming competence and be nice. And they had to cope with the work, regardless of their double burden of studying and working. Nothing else mattered to us.
Since Wolf and I (along with a few young employed computer scientists with academic diplomas whom we got through aforementioned body leasing and whose hours cost between 150 and 120 DM) financed the entire development, the young persons were rather free to come and go as they pleased. The only control was our assistant Heidi (Kaindl). Heidi was quite in charge of all the young persons, taking good care that everybody actually worked. The only times Wolf and I met them was during meetings (soon after our foundation, women, too, were employed).
In those days, Wolf had the role of SCRUM-Master and more (even though the word SCRUM did not yet exist). He told the team about quality. And that, first and foremost, they produced quality not for our customers, not for our sales partners Siemens and not for the InterFace Connection. Instead, being honest programmers, they needed to produce quality in their own interest. And Wolf had rather high standards and was very strict. If someone was not able or willing to deliver quality, he or she had no future at the “Connection”. But Wolf also protected the team, for instance when I tried to limit resources. And he made sure that we invested were necessary.
My task was perhaps that of the Product Owner. At least in the beginning. When I had been a young boy, I had been forced to learn stenography and typing. I used to love stenography, because it is a beautiful way of writing. It does not hurt your hand, as normal writing does. But I hated the typewriter. And I knew exactly how a good editing machine would have to look. I had also written it down in the time of our foundation.
When things got more complicated and, for instance, CLOU with its “embedded sql“ was added to our repertory, I transferred the role of Product Owner to our customers. And that was one of my best decisions ever. Because the customers actually were able to tell us their ideas about an automated chip processing. They showed us how to continue on our way.
One of our rules was that all employees – with the exception of Heidi – were able to program. Heidi was our first and most important customer. As soon as the first HIT version was available, we confiscated “nroff-makros”, her “office vi”, and she had to use HIT – which, incidentally, she did not appreciate at all. After all, the vi solution had not been so bad. Later, however, she learned to love her HIT. Surprise, surprise! After all, she was one of those who built it!
All other colleagues on the HIT team had to work hands-on. In other words, all of them had to be able to program, find errors and, above all, co-work (team work).
We were very early users of tools that would be commonly used a lot later. But this was only true for tools that actually made sense, such as “lint” for the quality control of our code or “sccs” for the source code administration. I am pretty sure that, time and again, we were the first in Munich. We were also earlier than most of the others using a “tracker” and an automatic “built”. But we never used planning software. Just as we always took pains to avoid “bureaucrazy”.
So all of us involved in the project were programmers. And we actually always coordinated in the team who was going to develop what. The personalities of the people involved were very diverse. But then, we also had the magic programmer. It was not entirely in jest that we called him “God”. But the first rule was that we were a team. Everybody helped everybody. Our motto was: “one for all, all for one”. Nobody was ever left in a lurch. And whenever you did not know a way out, you asked your colleague. Pair-programming in the strict sense did not exist, because it went without saying that this was practiced quasi automatically. Consequently, there were always several persons who knew the sources of the others. It was like an overlapping system that worked well some way or other without many words.
Of course, we had a rather complicated system with an awful lot of modules, interfaces, tools, API-s in our development. In total, a huge number of lines of code was produced. There were modules for the virtualization of keyboards, terminals or printers. We had developed the first National Language Support. Later, it became part of the X-Open UNIX implementation. We had complicated modules and modules everybody feared, as well as boring modules. Once in a while, we also had to find errors in the compilers we used.
The team always decided among themselves who was going to take on which task. Everything was part of the project: our value bank, mostly constituting of OpenSource components for source code administration, for the Built and the partly automated test, for the ports to the many end systems the Unix world then offered. Even producing the customer newsletter HITNews, which at the time was printed four times a year and determining the structure of the courses were part of it. Everything was done together, everyone .gave his best.
Naturally, once in a while there were situations when perhaps someone was unable to cope. Because maybe he did not yet have enough experience or perhaps he had underestimated the task. But then a colleague would help. The right person was always available. And when it was really necessary, there was still “God”.
Of course, everybody had his own role in the team. Each of us was a project manager and as such responsible for the appointments he had made. Some had more, others less. Each of us was a quality manager. Some more so, others less. Of course, there was something like a first contact for our customers and our partners. It was always a mutual decision (“who is the best for this job?”), but he remained in the team as a programmer. But, basically, every developer answered the questions of his customers. After all, they simply came into our office. The central bell rang, and whoever was the first to answer the telephone was talking to the customer.
Naturally, some of the colleagues were more concerned with integration, planning, configuration and the built-theme, the manual, … But every one of them was always fully integrated into the team in terms of technology.
But everybody always went back to programming. And everybody was responsible for top quality. For instance because they built automatic test environments simply as a part of the project. The responsibility was totally shared.
With the success came the necessity to have teachers for our product HIT/CLOU. During the first few years, all the developers also taught the courses. This was true for teaching the end users, the special users, the systems engineers, the operators and the programmers. Even the central persons, like Friedrich Lehn, the “father” of CLOU, taught courses where beginners were instructed on how to program CLOU.
There were instances when the developers did not appreciate this. After all, developing is much more important, isn’t it? But the courses were quite popular (because, after all, the colleagues knew what they were talking about, which certainly counterbalances the occasional “didactical” weakness). But the great thing about it was that our colleagues always knew exactly what the customer wanted and needed! This is how the customers as a whole became the Product Owners.
Due to these inter-disciplinary tasks, our colleagues grew both in technological competence and personality at enormous speed – that is also true for sales competence. More often than not, it was unbelievable how young students became experts with a huge self-esteem after a few months.
Without ever saying it out loud, we on our team understood even at that time that it is all about making all the persons in the team and in the enterprise look biggger instead of smaller. And to make them be part of everything and share everything. We knew that we often had to have really steep goals, often even bold goals. Otherwise, we would never have managed our product. But we also knew, especially in this situation, the importance of living a strong error tolerance.
The colleague in the team or the customer must never ever be the enemy or adversary. Instead, the only enemies were the challenge or the detrimental circumstances.
Wolf and I were the “management”. But we were more like visitors in our enterprise. After eight to ten hours with customers every day, we came back to our employees at home in the office for recreation. They were all our friends, it felt good to be near them. And they showed us all the great things they had, again, created. We gave our feedback and then disappeared to our next day of consultancy.
And whenever a nice result was achieved, we all celebrated. It was the best time of my life. We learned so much. We also learned that thinking normal and conservatively is often nonsense. For instance, I always wanted to deliver to our customers on time. And I had to learn that this is utter nonsense.
Because if you want to create something really innovative, you will learn again and again that deadlines do not make any sense at all. It simply will not work. If a deadline can absolutely not be met, then all that matters is a functioning communication and looking for a solution that satisfies the customer. Because when they are all in one boat and want to be a success together, then there is always a solution – and we found out that it can always be done.
I already hear your objection: Well, it might work for a small project. But what about a huge project?
To be sure, we were perhaps less than 50 persons. But the very same projects had failed with more than one huge concern. They had often used five times as many persons as we or even more. Expensive, experienced and highly qualified ones. But it did not work.
I believe it can be done in the same way if you have a huge or even a very huge project if many such great teams are linked and cooperate with good-will.
RMD
(Translated by EG)
Loading ...