Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

08.12.1995

OO-Einsatz in der Praxis: Von Naegeln zu Schrauben

Kim Lesden Anwendungsentwickler und Berater in Muenchen

In der Baubranche gibt es einen neuen Trend: Schrauben sollen Naegel ersetzen. Schraubengurus versprechen kuerzere Bauzeiten und leichtere Instandhaltung. Die Handwerker moechten natuerlich mit den aktuellsten Werkzeugen arbeiten, und das Management verspricht sich davon, endlich den Rueckstau an Bauvorhaben aufloesen zu koennen.

Also werden die Handwerker mit Schrauben und Schraubenzieher ausgestattet und der naechste Bau angegangen. Beim Bauen passiert dann oft folgendes: Jemand, der sehr gut haemmern kann und mit Naegeln wunderbar baut, versucht zunaechst, auch die Schrauben einzuhaemmern, und da schau her - in kurzer Zeit ist die erste Wand errichtet! Der Handwerker ist stolz, das Management zufrieden, beide uebersehen nur, dass die Sache einen kleinen Haken hat.

Dass mit Schrauben und Haemmern auch ein Haus gebaut werden kann, verleitet naemlich so manch einen Handwerker und die meisten Manager zu dem Irrglauben, man habe den Umstieg von Naegeln auf Schrauben geschafft, und man beginnt folglich sofort mit dem Bau eines Hochhauses.

Tatsaechlich aber ist die Qualitaet des Baues entgegen den Versprechungen der Schraubengurus nicht besser geworden, sondern erheblich schlechter, weil die Schrauben nicht sachgemaess verwendet wurden. Dieses faellt aber erst mitten in der Bauphase auf und wird deswegen von den meisten Beteiligten entweder unbewusst verdraengt oder bewusst ignoriert: Man kann den Bau ja nicht wieder abreissen, und so werden die oberen Stockwerke teils verschraubt, teils zusammengenagelt, waehrend die unteren Stockwerke zusammengenagelt bleiben. Fazit: Der gesamte Bau ist einsturzgefaehrdet.

Was hat das alles mit DV zu tun? Viele erfahrene DVler (Programmierer, Designer, Analytiker), die auf eine objektorientierte Umgebung umgestiegen sind, benehmen sich wie die oben erwaehnten Handwerker: Sie bedienen die neuen Werkzeuge in altbewaehrter Manier. Weil sie bald damit produktiv werden, setzt das Management nach kurzer Einarbeitungszeit traditionell kalkulierte Ziele. Im Glauben an die von den OO-Gurus versprochenen Produktivitaetssteigerungen werden diese Ziele im Laufe der Zeit staendig nach dem olympischen Motto geaendert: schneller, hoeher, weiter.

Die Entwickler, die sich in der Anfangseuphorie nicht gruendlich mit der objektorientierten Materie auseinandergesetzt haben, planen linear statt spiralfoermig iterativ (schrittweise), was dazu fuehrt, dass anfaengliche Fehlentscheidungen nicht rueckgaengig gemacht werden, sondern mit grossem Aufwand umgangen werden muessen.

Dann kommen weitere Wuensche des Managements dazu, und das Ganze wird noch wackeliger. Der Teufelskreis ist perfekt - die Qualitaet ist dahin, und den Beteiligten geht es nur noch darum, die staendig wachsenden Kosten und Aufwaende zu rechtfertigen und den Schwarzen Peter einem anderen zuzuschieben, waehrend das Projekt eine Eigendynamik wie eine Lawine entwickelt, die niemand mehr unter Kontrolle bekommt.

Wie den Teufelskreis durchbrechen? Das Management muss einsehen, dass die objektorientierte Entwicklung ein iterativer Prozess ist, der demnach auch kalkuliert werden muss. Dabei ist es durchaus moeglich, dass, um die Qualitaet des Produkts zu gewaehrleisten, zwischen zwei Schritten nichts produziert wird (unveraenderter Leistungsumfang) oder dass sogar voruebergehend eine negative Produktion entsteht (Minderung des Leistungsumfangs). Wer Objektorientierung will, muss das in Kauf nehmen.

Die Entwicklung ihrerseits muss einsehen, dass mit einem neuen Werkzeug meistens eine neue Arbeitsweise einhergeht, die unter Umstaenden von Grund auf neu erlernt werden will (auch wenn wie zum Beispiel bei C++ die alte, von C bekannte Arbeitsweise zunaechst in wesentlichen Punkten uebernommen werden kann).

Die Entwicklung muss auch dem iterativen Prinzip Rechnung tragen: Die eigene Arbeit muss staendig in Frage gestellt werden bezueglich der Handhabbarkeit, der Flexibilitaet und der Wartbarkeit der entstehenden Anwendung. Fehlentscheidungen muessen geaendert und Schwachstellen behoben werden, bevor die Entwicklung weitergeht.

Das erste OO-Projekt durchzufuehren und Know-how aufzubauen kostet Geld und Zeit. Wird es korrekt durchgefuehrt, spart man diesen Aufwand bei der Wartung und beim naechsten Projekt locker wieder ein. Tappt man jedoch in die beschriebene Falle, wird das naechste Projekt genauso teuer und genauso verspaetet, und es bleibt nur die Flucht nach vorne, indem man auf neue Vorgehensweisen wie Programming in the Large oder Componentware zur Loesung der eigenen Softwarekrise hofft. Diese Werkzeuge aber wollen mit Sicherheit auch korrekt bedient sein, damit der Schuss nicht nach hinten losgeht. Hiermit waeren wir wieder beim Thema: Von Naegeln zu Schrauben..