Zusammenfassung

Was ich explizit nie wollte war Softwareprodukte zu entwickeln. Doch erstens kommt es anders und zweitens als man denkt. Viele Jahre vor Studienende habe ich Software entwickelt; als Keyboarder mit DX7 war das die einzige Chance, dieses Musikinstrument auf bestimmte Weise zum Klingen zu bringen. Jedenfalls gefiel dies dem Gründer eines Softwarehauses, der ein sehr erfolgreiches Textsystem zur weltweiten Vermarktung geführt hat und der Grafik in die Texte eingebunden haben wollte.

Nun, wer Synthesizer steuern kann, kann auch Drucker steuern, ein Physiker versteht was von Vektoren und Mathematik. Was also läge näher, als zusammen zu arbeiten? Nun, die folgenden 11 Jahre haben die Richtigkeit dieser Idee bestätigt.

Mit der Zeit wuchs der Aufgabenbereich; irgendwann waren proportionale Schriften mit auszugeben, medizinische Dokumentation anzureichern, Formulare zu gestalten und Archivsysteme einzubinden, denn aus dem Grafikeinbindesystem wurde ein allgemeines Ausgabesystem.

Während die Aufgaben an einem Softwareprodukt stetig zunahmen, veränderte sich auch die Aussenwelt weswegen Allianzen geschmiedet werden mussten wie zum Beispiel mit StarDivision und Microsoft, was gleichzeitig die Einführung von objektorientierte Programmierung und später dann auch Festlegung auf bestimmte Plattformen bedeutete. Letzteres rührte aber direkt an ein wichtiges Grundprinzip des Unternehmen, das sich auf die Fahne geschrieben hatte, die komplette Softwarepalette auf allen Rechnersystemen zur Verfügung zu stellen.

Der daraus entstehende Konflikt zermürbte über Jahre; bei der Rückbesinnung über die selbst gestellte Aufgabe, Beiträge zu nachhaltiger Produktentwicklung leisten zu wollen, gab ich neuen Herausforderungen darin den Fokus.

Hintergründe

Natürlich war 1985 die Computerwelt nicht so wie heute. Die IBM und Siemens Großrechner dominierten den Markt und es gab noch die VAX und UNIX stellte sich auch so langsam als markttauglich heraus. Den PC gabs auch schon, virtuell war er aber auch schon seit Jahren in Form des VM/CMS verfügbar.

Eine Reihe anderer Lösungen gab es auch schon: CATIA, mit dessen Hilfe technische Zeichnungen angefertigt werden konnten und die in Texte eingebaut werden sollten. Also war es nötig, eine Schnittstelle zu definieren um die Grafikdaten benutzen zu können.

Weiter musste die Software auch Formulardaten, möglichst dynamisch zeichnen und Logos einbinden.

Beim weiteren Zusammenrücken von Lichtsatz und Massenschriftguterstellung, war die Ausgabe von Proportionalschrift wichtig.

Als Rahmenbedinungen waren als Programmiersprachen auf Großrechner und PC nur Assembler schnell genug, bescheidene 64kB Speicherplatz für ein Modul auf dem PC schrumpften auf dem Großrechner schnell unter 6kB, wollte man nicht verhindern, dass bei den anderen 1.000 Mitbenutzern des Großrechners die Lichter nachhaltig für Stunden ausgingen.

Aus heutiger Sicht undenkbar, die komplette Entwicklung von der Feinspezifikation bis zum Pflichtenheft, Marktbeobachtung, Produktezukauf, Personalaufstockung, Marketingmaßnahmen, Kunden- und Lieferantenverhandlungen dieses Grafikprogrammumfelds in den Händen einer Person! Das schloß natürlich Maßnahmen zur Einführung von Entwicklungsprozessen ein und war ein umfangreiches Studienfeld zur Kreativitätsforschung.

Herausforderungen

Also Assembler ist im Gegensatz zur Auffassung mancher Leute keine wirkliche Herausforderung. Jedenfalls keine im Vergleich zur Änderung der Überzeugung gestandener Programmierer, auf eine andere Entwicklungsumgebung wechseln zu müssen. Natürlich war schnell herausgefunden, daß manGrafikprogramm mit Maus und Tastenbedienung zwar auch in Assembler schreiben kann, dass dies Vorgehen aber nicht effizient ist.

Die Anwendung von Objektorientierung mit damals Borland C++ als beste Implementierung erfordert die stärkere Einbindung von Lieferanten für Objektbibliotheken mit allen rechtlichen Konsequenzen und dedizierter Lizenzpolitik. Eine echte Herausforderung wird es aber dann, wenn man von Borland C++ auf Microsoft Visual C++ wechseln musste, weil die Chancen im Wachstumsmarkt NT (3.51) erheblich größer sind, als im UNIX-Durcheinander oder auf Seite des sterbenden Großrechnerangebotes.

Neben der grossen Freude, welche die Herausforderung der Abbildung mathematischer Zusammenhänge in Assembler bereitete, waren die wirklichen Herausforderungen in der Führung des Mitarbeitertyps Softwareentwickler, die Anbahnung und der Abschluss der Kooperation mit StarDivision und Marco Börries sowie eine störungsfreie Zusammenarbeit mit Microsoft in rstützung und Koexistenz.

Bemerkenswertes

Ein von mir entdeckter größerer Fehler in einem Softwaremodul der AIX der IBM wurde von der IBM nach Entdecken innerhalb von 24 Stunden repariert, an den Kunden ausgeliefert und deployed. Dies hat mich bemerkenswert beeindruckt.

In einem Projekt bei einem großen bayrischen Stromlieferanten mit dezentraler IT-Architektur sollten meine Objekte von den OS/2 Systemen über einen AIX Knoten in einendows (3.11) und IBM-Großrechnerumgebung (MVS) hin und zurück transportiert werden. Dazu nutzte ich eine Funktion, die den Aufrufenden informiert, ob eine Datei in Benutzung ist oder nicht. Das hat zwischen OS/2 und der AIX nicht funktioniert.

Erst glaubte mir die IBM nicht, nach Übersendung eines kleinen Überzeugungsprogramms aber schon. Dann begann die Uhr zu ticken und die IBM überzeugte nachhaltig.

Ergebnis

Die Art, Software zu entwickeln hat sich zwischen früher und heute nicht wesentlich verändert. Lese ich heute über SCRUM, so haben wir damals schon so entwickelt, ohne es so zu nennen.

Ich habe nie wieder eine Firma gesehen die Produktentwicklung auf diese Weise gestattet, wobei sie eine hervorragende Möglichkeit ist, in  einem Umfeld begünstigender Kreativität strukturiert vorzugehen und weil ohne Mangel im Ergebnis beste Resultate liefert.