Sorry, this entry is only available in German.

If production nd development chains become too complex, they might easily break (down).

I got the ideas for this article during a short discussion about whether or not our developed society might – technologically – regress into the pre-electrical era. The person I discussed it with thinks such a thing is not possible. This firm believe made me thoughtful.

A small brother and a very small brother of the flat package I describe. The telephone shows how small the individual parts are 🙂

In the early 1970ies, I studied mathematics and computer science at Munich Technical University. I was also a student working for Siemens. After all, they had great computers and students could really make good money, considering the times.

My working place was in the “Koppstrasse” camp buildings. Our tests were conducted in the Feurich-Building – which was in the Siemens AG central building at Hofmann-Straße. Life in the camp was great, it was truly an F&E atmosphere, just like you would wish to find it today with a good start-up.

I already described my first project in the IF-Blog. It was about calculating the biggest possible Mersenne prime numbers. The task was one for people who liked working by themselves.
Then I became more and more part of the team and almost intoxicated by the challenges of our task. Together with other colleagues, I developed the PALOG-A- and PALOG-B systems.

PALOG is short for “PrüfAutomat für LOGik”. A PALOG-A device was supposed to test the function of “maxi flat modules” that were built serially. These modules had various functionalities in big computers. The functionality and correctness of the underlying logic had already been tested.

All we had to do was check if the serial production was error-free and if the manufactured components rendered the desired results reliably. I will explain the extended function of PALOG-B later in this text.

A maxi flat module is a huge board; it is rather broad and thick, but not very high. The boards you see on the picture are from a later time and were a lot smaller.

On one side, a maxi flat module had 128 pegs that had to be pressed into the rear wall of the big computer. The computer fed the board with digital patterns following the number of pegs, then the board returned a result and further processed it.
(I might be wrong and the number of pegs was only 64, but I seem to clearly remember 128.)

On the surface, the board was full of electronic modules that had a few larger or many smaller feet. These feet were pressed into the pre-arranged holes of the board. The entire construction was then brazed and soldered from underneath. In case of serial production, it was done by a dipping solder bath.

Sometimes, the building modules on the board we used had been developed and produced by Siemens. Some of them had to be bought. I particularly remember chips by Motorola that sometimes cost up to 1,000 DM.

If some of what I said here is not correct, please forgive me. I never specialized in hardware, instead always developing software.

The placement and soldering processes were far from trivial. Consequently, it was absolutely possible – and it happened quite frequently – that these maxi flat board modules rendered no or erroneous post-manufacturing results. Sometimes the individual parts delivered along with the products were also faulty.

But how can you find out about this? How can you test such a maxi flat board module?

Our method was quite simple. We sent bit patterns into the objects to be evaluated and then checked if the answer was the right (expected) one. Naturally, for reasons of efficiency, you cannot conduct such a test for all kinds of input patterns. It was the task of our software to generate relevant patterns that made it possible to prove with as few test steps as possible that the logic of the maxi flat board module worked correctly.

Back to the younger and smaller brothers of the maxi flat board module.

To this end, it was mounted in the PALOG-A machine and sent over the 128 pegs according to their functionality. The answers were compared with the desired results. If the actual test patterns were identical to the desired ones for all test patterns, then it was validated that the maxi flat board module worked without a glitch.

Seeking and finding the relevant test patterns was not at all easy and we developed it from the functionality following a rather “mathematical” procedure. The programming was a “cross” procedure on BS1000 and soon also on BS2000.

The actual patterns, along with the correct answers, were generated on process computers of the 300 series. Incidentally, they had a 6-bit assembler with two accumulators beautifully named PROSA. The “three-hundred-computers” were reputed to be incredibly fast.

The 306 was the top model. But even this Siemens machine that, at the time, was considered the fastest ever, easily took a week or more for calculating the necessary patterns.

In those days, the computer rarely ran for an entire week without breaking down. Mostly, it would break down within such a long time period at least once. Consequently, the software had challenges besides the algorithmic one, such as the reloading of the program in case of a system breakdown. At the time, this was not at all a matter of course.

Well, so far so good. At least, PALOG-A allowed a reliable validation about whether or not a maxi flat board module was free of errors. But quite frequently, we had poor product quality. What to do with that? The very fact that the construction elements were so expensive was a discouragement against destroying or dismantling them. Not much would have been won by this, anyway. Consequently, it was desired that all of them can be repaired.

If you wish to repair an error in a complicated flat board module, you will first have to find out where exactly on the board it is. In our case, you cannot simply solve the problem by logical thinking or code reading as in a program. Neither did we have a debugger. After all, the question is which individual part of the module is faulty, which soldering does not work, or similar problems …

This is where our system PALOG-B came in. Whenever a PALOG-A maxi flat board module was discovered to be faulty, it was transferred to the PALOG-B system. As soon as it arrived there, it was subjected a (so-called) PFAD procedure, i.e., it was processed with totally different test patterns. The returned data made it possible to circle the error on the board. This is how we managed to correct all possible mistakes by multiple circling. Afterwards, the board was again tested with PALOG-A – and if it worked, we celebrated.

I am sure you can easily imagine why the procedure was called PFAD. It is German for PATH and all the different input patterns had to run through the various paths. And as soon as you determined which of the many possible paths does not function, you are a lot closer to finding the bug.

I tried to describe the procedure as simple and comprehensible as possible. In reality, it was a lot more complicated and based on know-how that had been developed and handed down over many years.

Our software was only a small part of the design and construction software necessary for the efficient development and production of IT systems. At Siemens AG, they continued to work in huge steps. A few years later, the Siemens AG had an extensive work bench consisting of many software systems for the development of their chips. It was probably far superior to all the competition.

Unfortunately, I forgot the abbreviation, but I do remember that the application allegedly was the world’s most complicated software solution and contained the most lines of code of all the known programming systems.

And then the downward spiral for the data processing area started and all the know-how disappeared.

But then who cares about the “delights of yesterday”?
Let gone-byes be gone-byes!

I can easily imagine that the know-how and toll chain you need to develop and produce an Intel processor or an IBM Power today are by far more of a challenge than the rather limited flat board modules.

And it is quite possible that, today, not only a high tech processor, but also a “simple” electric motor or power generator simply cannot be produced without a similarly complex machinery. And what happens if – for whatever reasons – such a machinery breaks down?

This is where the circle closes and I return to where this article started. The total immersion of these tool and production chains in all technologies and sectors – chemistry, energy, farming, mechanics, pharmacy, physics,… – I can easily imagine that our system might collapse and we will have to start at ZERO. And that may not be easy.

(Translated by EG)

I wrote the technological issues totally without checking back in any documents, only relying on my memory. Unfortunately, Wikipedia is not really much help with such exciting computer science topics. I find it a pity that, especially when it comes to the very technology that made Wikipedia possible, there is mostly no sufficient description of said technology to be found on its pages.

So please accept my apologies if I occasionally did not remember the correct abbreviations or made similar mistakes. There was nowhere I could look up anything that could have helped my memory. So much the more would I be grateful for any corrections and notes on the technology I described.

Die Winderhitzer der Völklinger Hütte.

““Die Winderhitzer der Völklinger Hütte”. Also Vintage”

Regardless of the fact that I consider email vintage technology, I still have some email addresses. Many useless and stupid messages arrive.

It is my task to then delete those emails and ask my communication partners if, please, they could use other ways of communication.

Today, something happened that made me smile. I received an email from a beloved and long-time friend whose technological competence I rather appreciate.

He sent an email to a lot of people ( (

Could you please leave us alone with this totally irrational discussion!!!!!
I, too, said what I think about mail distributors and internal mail in the survey about new communication forms.
This is another typical example illustrating the fact that intra-company emails are total nonsense and why email distributors inparticular should be immediately made redundant.
To all, and I really intended to write this!

Incidentally, the “totally irrational discussion” was about the problem with rechargeable i-phone batteries and their exchange.

I replied as follows:

Your email made me smile. 🙂
After all, I totally agree with you – except that I am even more radical. Email is no longer a general communication channel. Instead, it is a totally old-fashioned one which – it goes without saying – should no longer be used in modern enterprises.
Emails to third parties should only be sent in those few instances where in former times you actually wrote a letter, sent a telegram or went to a public phone booth. Everything else should be done with tools that are adequate to the task.
Best wishes and a nice weekend to you!

Yes, I, too, dislike emails. More often than not, they have huge footers made even larger by artificial nonsense and totally uninteresting advertisements or stupid legal disclaimers.

I hate email dialogues that cause a constantly growing series of email incarnations through more and more dialogue steps. With every reply, you create a new email that contains the same as before, with the addition of the last reply.  When the internet was first introduced, they made an attempt to make the design of email communication a little more agreeable. For example there was the so-called tofu rule.

Unfortunately, however, “tofu” was only applied by very few users and consequently failed.

As a general rule, communication will be carried out as a “thread“. Ever since we have the perfect chat, email is mostly obsolete. In the “peer2peer“ thread, I can always immediately see what has been recently said. That is also true for persons with whom I rarely communicate – where it is extremely valuable. Threads are also a good tool for more than two persons who wish to communicate. If you use email, you immediately get a catastrophic flood of “cc”-s and “bcc”-s.

Moreover, I enjoy using images, audios or small videos in my daily communication. How cumbersome is this both for the sender and the recipient if you use email? Just look how easily bbm, wechat, whatsapp, the FB “messenger“ or Skype, the twitter  “dm“ (direct message) etc, work. Not to mention Snapchat, the system with the most modern and simple of all user interfaces.

Even better for structured communication, even in bigger teams/groups than chat systems are “communities”. There are many communities in the internet, for instance in Google+. They show you how it is done. And how you can communicate well and yet very structured and highly efficient with very simple means within an organization. And how you can do totally without the email nonsense, rather than flooding the non-interested and non-concerned parties with spam all the time!

Note also:

The telephone is also OUT. I only use my telephone after having made an appointment in advance to do so, if there is something important I need to do or if I want to talk with someone and pay full attention. Consequently, I no longer use the telephone in the car or in public places like trains. And even for important issues, I only use the telephone if image telephones (Hangout, Facetime, Skype, Cisco, Citrix …) are not an option because the person at the other end prefers the good old telephone.

In case you forgot: the “telephone” function on the smartphone is also just an app for synchronous spoken communication that enables your connection with addresses made up from telephone numbers (digits) and through “voice-over-IP“.

If someone calls me and I reply with
“Now who interrupts me in my work?“,
then I kindly ask you to forgive me.

I continue to be available on the telephone for all those who need me. Here is my physical telephone address 0049 171 4850115 (unfortunately, the symbol telephones have now been out of fashion for a long time). But, please, only call if it is really important and totally urgent!

In all other instances, please ask yourself if it might not be enough for you to use asynchronous (spoken) messages through one of the chatters I use or, if it is about a specific topic, for you to send a message to the respective community.

(Translated by EG)

CLOU/HIT at InterFace Connection

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.

if-logoProjekt 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.

(Translated by EG)

Hans Bonfigt
Monday November 2nd, 2015

Drei glorreiche Halunken

Mißerfolg ist planbar.

At the 30-years of InterFace jubilee party, Gerhard Saeltzer was one of the guests of honour. Being the surprise guest from Dresden, he had prepared a wonderful speech. As the party progressed to become a rather excessive and noisy affair, there was, unfortunately, no opportunity to give this speech its due place. The first part of the speech describes a rather impressive chapter of East-German/West-German history. InterFace and yours truly were lucky enough to witness some of this history first-hand during the very early stages.

It is truly nice that you all exist!

Dear Roland Dürre, dear InterFace folks, dear guests!

Today, we meet to celebrate the thirtieth birthday of InterFace. Many thanks for the invitation, which I gladly accepted. I immediately decided to come here with my wife.

It is truly nice that you all exist and that we all found each other here today!
Let us remember some events of 24 years ago. It was the time of the German Re-Unification. What exciting and upsetting times those were! And how frustrating they were in East Germany! For instance, Germans from Bavaria came to visit us Saxonians – and they spoke a language that sounded totally alien to our ears. And the second word all those Bavarians uttered was one that had been totally eradicated in the East: God. Wherever you saw them, you heard them say: “Grüß Gott“ – the only thing the Saxonians could do by way of reply was to give an embarrassed and shy “Na goodden Taach“.

And we also learned that the Godly greeting was accompanied by something else: the church tax collected by the federal tax office and often shockingly high back pays for us persons living in the East. And then something extraordinary happened: countless special knights stormed into the East – fortune-hunting knights and robber-knights. Along with attorneys and politicians, counsellors and realtors, functionaries and unionists. Many of them – let us be honest about this – had become redundant or put to pasture in the West. In no time, the con artists came: the car salespersons who sold four-wheel junk as new cars. The textile merchants who sold used clothes as new. The quick property hunters who bought huge dilapidated East-VEB’s for one DM, then demolished the houses and sold the property for millions. And the agents for all kinds of things and totally useless items, above all for life insurances. I, too, unnecessarily, “nibbled”.

In the East, I met attorneys and civil servants from the West who, for example, did not even know that you had to put your signature underneath a legal complaint before you submit it at court. And even show-masters and magicians turned up. One of them actually came right from heaven – he landed in Dresden with a borrowed helicopter – like a God of Fortune. He built a new suburb of Dresden in a swampy area, sold the best soccer players and eventually disappeared behind prison bars. And there were also great IT counsellors who were really absolutely incompetent. They did not even know the meaning of the words software engineering and software quality.

Well, my dear Bavarians, you can imagine how, after the re-unification, there was plenty of frustration and negative culture shocks in the East. We had to undergo a total re-programming. And then, all of a sudden, a miracle happened. I witnessed the reverse, some kind of positive culture shock. In Dresden, I met the entrepreneur Roland Dürre and parts of his young team, his wife and even his youngest offspring Rupert.

Now this man was totally different. He was an entrepreneur who did not just talk big, but was competent and knew what he was doing. A man you could talk to, from man to man, without arrogance. He met me at eye-level without first looking at the contents of my purse (it was empty, anyway) before starting to talk. A man who, even as the head of the entire firm, met his employees like family, wearing felt slippers. With his athletic and unpretentious life-style, he used soap from army supplies for his daily ablutions, rather than certain perfumed chief soaps. Roland Dürre, the entrepreneur who was such a good listener. A man who it was a pleasure to talk to and to cooperate with. A flexible team manager in the truest sense of the word.

Well, let me put it bluntly: for me as someone who was frustrated with re-unification, Roland Dürre and his team looked like extra-terrestrials landed from another, positive star. And they successfully mastered the last 30 stormy years! And I admire all those at InterFace who were part of it.

You all are just terrific! It is so nice to have you all here!

Many thanks to Roland Dürre for this silver lining I was permitted to experience, this East-German/West-German post-re-unification culture shock! Dear Roland Dürre! In those days, we both were quite bold, deciding to organize the first East-German/West-German technological conference for modern software and application systems SoftSys 9/90 in Dresden. Regardless of our rather limited resources, we were both even faster than the high and mighty politicians.

As early as 9 days before the re-unification on October, 3rd, 1990, our East-German/West-German re-unification conference took place in Dresden! The good communication between the two of us had some considerable effect. Everything was done faster. Later, unfortunately, our connection came to a standstill. 

ComputerweltSo much the more wonderful that, after 24 years, we re-united. I found InterFace on the internet when I entered my own name and accidentally found a book review  about my computer science book for children and later for primary school in Saxonia: ”Erstaunliche Computerwelt“.

Dear Mr. Dürre, dear InterFace Team!

Looking back makes me a little sad: unfortunately, there are currently far too few enterprises in Germany and Europe where such a nice, communicative, faire culture is lived as at InterFace. In these times of company bankruptcies and mergers, where quite a few enterprises have not survived, you managed to stick it out on the market. Wonderful! Many others could learn from you.

I admire you!

It is really a pity that, as of today, science has not yet mastered one art: perfect cloning. Both Germany and Europe would be better off if you and your enterprise could be cloned – maybe five times, or, a little more boldly, 20 times! And since, unfortunately, this cannot yet be done, they really should erect a plinth or at least a memorial table for InterFace here in Unterhaching. Well, even if they cannot do that at the moment, here are my heart-felt congratulations – you might find some similarities to Theodor Fontane:

”May sorrow be lame, may worries be tame!

Hear our wishes for the birthday child:

Another thirty years unharmed and mild!“

And, my dear Roland Dürre, here is another small wish for the future – because it is such a pleasure to cooperate with you. How about a new shared project with world-wide potential? I have an idea I would like to discuss with you.

Best health and good luck for all of you!

Grüß Gott! Godden Taach, and so long – perhaps with amusing anecdotes from my life with the computer in the East! You are all cordially invited!

Dr. Saeltzer, Unterhaching, June, 27th, 2014

Hochzeit im FlußThe invitation was for the session “fascinating things and anecdotes around the present and the future of computer application” by Dr. Saeltzer during our 30-year-jubilee party. In this session, he told us amusing things about the start of IT in the GDR during the 1960ies. He also took the role of helping to build courage and showed with small reading sessions from his book “Wedding in the River” (which is an “introduction to resilience”) how people can retain optimism even in grave situations, such as the Dresden flood catastrophe.

When I read this text, my ears turned purple, but I was certainly very delighted.
My most heartfelt regards and many thanks to Dr. Saeltzer.

(Translated by EG)


Here are a few catchwords to characterize our “surprise guest” Dr. Gerhard Saeltzer:
Computer Scientist, Software Technologist, Simulation Expert, Author, Speaker, Trainer (more than 10 books, among them best sellers, 100 printed technological reports, 1,000 presentations and seminars, exposes for educational TV), entire pages and interviews in the daily newspaper devoted just to him, Chairman of big technological conferences in the East, Designer of Innovations such as ProgFox, LEMA. His last position was as governmental director of the Saxonian data-security center in Dresden. Currently, he is in anti-retirement; he has been jogging through Dresden for 20 minutes between 6 a.m. and 9 a.m. on a daily basis for the last 45 years.


The text is the original by Dr. Gerhard Saeltzer. I added the two pictures of the books mentioned in the article.

Roland Dürre
Sunday November 21st, 2010

brand eins in December – Unpredictable!

A Family’s Economy

always associate in life – so I am also doing it with the newest “brand eins” edition.


I like that! After all, I am currently writing an article on Operation Research (OR) and entrepreneurial research. According to Wikipedia, it is the same thing. I, however, would demand that entrepreneurial research be more concerned with leadership and entrepreneurial culture than with trying to force enterprises to follow mathematical models, like OR.

The Family’s Economy

Naturally, family is important for me. What would I be without? Especially as an entrepreneur, I find family great: a family is nothing other than a small enterprise and you – especially if you are a woman – need quite a bit of entrepreneurial spirit in order to start one.
But follow me through the magazine:

mehr »

Roland Dürre
Tuesday October 26th, 2010

HITPC, the Manikin and the Rail Car

Today, I will give you a short insight into the past of InterFace!

At InterFace, there are always plenty of small items embellished with the IF logo. I believe it helps with creating identity – and I know that many enterprises highly esteemed by me do the same. Moreover, we, too, give our employees a nice Christmas present each year – of course one which also displays the IF LOGO.

As the years go by, quite a few items have been added to the list: the box of peppermint pills and the InterFace jacket, various kinds of mugs and dinnerware, even a pan for cooking Bavarian veal sausage, sports bags and clasp knives.

At one time, we had a small figurine. We called it the
“HITPC Manikin”

Our text system is not only available for UNIX, but also for PCs. Mind you, we are not just talking the German version, but also, for instance, the Russian (Cyrillic) one!

And as an extension to the UNIX-HIT-CLOU work benches, the HITPC was quite widely used, even with DOS. We designed the HIT-PC manikin especially for the DOS users. It always cut a fine figure on the then rather clumsy-looking PCs.

The beautiful advertising character made of plasticine (Plastilin) was designed by Hildegard Heidecker. She gave face and shape to our service idea.

In those days, we also had an (original) “Märklin” rail car for InterFace Connection. It also showed the HIT PC manikin. The number of vehicles ordered was very limited (I seem to remember it was 200, but I am not quite sure) and we gave them to our customers and employees as a Christmas present.

The rail car also made it into the Koll-Catalogue (Koll-Katalog) for Märklin advertising characters and (is said to have) achieved a rather high collector’s value.

It all happened more than twenty years back.

(Translated by EG)

On the second floor of our building at Unterhaching – directly next to the reception area – you can admire a gold-plated HITPC manikin. Frau Heidecker gave it to us on our 25th anniversary! And, of course, you can also see one of the Märklin railway cars in my office.

Roland Dürre
Sunday July 11th, 2010


Shortly after having graduated from high school, in 1969, sitting in a computer science lecture by the great professor F.-L. Bauer, I first heard the term “context sensitive”. There was a lot I did not understand during the first semester. The same is true for some themes with pictures in the book that was supposed to accompany the lecture “Informatik I”, the famous yellow “Bauer/Goos”.

Many years later, now on a friendship basis with F.-L. Bauer and after many private discussions with him and visits to the computer science section in his company to the “Deutsches Museum”, I finally understand what informatics is all about.
A similar thing happened to me with the term “context sensitive”. The term was relevant for me whenever talking programming and programming languages. During my programming career, I soon realized that self-made software with all its corrections and modifications must be free of “context sensitivity”.

Compared with inter-human communication, the description of a problem in a formal language or the solution of said problem with a programming language seems literally trivial. But especially in real life, “context” plays a significant role.

mehr »

Roland Dürre
Thursday March 11th, 2010


On Tuesday, March, 9th, they elected the workers’ council at Siemens Neuperlach. Throughout all the parts of the building still used by Siemens, the loudspeakers were heard inviting everybody in German and English in the most urgent terms to vote. It was so loud you had to interrupt your meeting.

Although I had spent plenty of time behind these walls during my life, this was the first time I heard the loudspeakers consciously. I am always a little moved by loudspeaker announcements in buildings. The reason must be a mixture of school, armed forces and Orwell.

All the time, some rumours are spread behind the fences at Siemens Neuperlach. Still being on friendly terms with quite a lot of people there, I am informed about all the newest whenever visiting.

mehr »