Entwickler von Geschäftssystemen haben einen schlechten Ruf
Agile, Scrum, ausgefallene Worte für das Schreiben von Software, die liefert
Ganz gleich, wie man es betrachtet, Entwickler von Software für Geschäftsanwendungen haben im Allgemeinen einen schlechten Ruf. Systeme werden fast zwangsläufig verspätet oder gar nicht geliefert. Der durchschnittliche Benutzer in einem durchschnittlichen Unternehmen verbringt jede Woche buchstäblich Stunden damit, über die Computersysteme zu meckern, die er ertragen muss. „Warum ist das so?“, „Was zum Teufel bedeutet das?“ sind ein paar Dinge, die ich täglich höre.
Ich habe Jahre damit verbracht, Geschäftssysteme zu schreiben, und die meisten Benutzer waren positiv darüber, was sie bekamen und verwendeten. Systeme, die nach einer anfänglichen Spezifikation geschrieben, auf Herz und Nieren getestet und dann bei Bedarf zu einem vereinbarten Preis angepasst werden, falls dies erforderlich ist. Kontinuierliche Unterstützung für den Kunden und nachhaltige Einnahmen für das Softwareunternehmen waren eine erfolgreiche Kombination. Die anfängliche Spezifikation basierend auf einer detaillierten Anforderungsanalyse wäre immer eine funktionale Übersicht und würde keine Code-Besonderheiten enthalten, ich glaube, ich habe einmal Pseudo-Code verwendet (als ich Spiele geschrieben habe). „Das ist, was wir brauchen“, war normalerweise gut genug für mich. Abgesehen davon waren es einige Modelle von Benutzeroberflächen und eine Menge Datenbankdesign, und los ging's. Die Test- und Optimierungsphase des Entwicklungslebenszyklus war sehr wichtig. Die Systeme wurden im Allgemeinen pünktlich geliefert und funktionierten.
Heutzutage (ich hätte nie gedacht, dass ich das jemals sagen würde) dreht sich alles, was mit Systemen zu tun hat, um Planung, noch mehr Planung und dann um Wiederverwendbarkeit. Was mir so fremd erscheint, ist, dass ein Großteil dieser Planung nicht darauf abzielt, eine funktionale Anforderung zu erfüllen, sondern vielmehr zu beschreiben, wie und warum wir schreiben werden, was wir schreiben, wenn wir es schreiben. Hoffe das macht Sinn? Warum etwas in 10 Zeilen schreiben, was Sie in 1000 tun könnten, wenn Sie es „vielleicht“ in 2 Jahren wiederverwenden müssen? Persönlich habe ich noch nie etwas geschrieben, was ich 2 Jahre später nicht besser umschreiben könnte. Ich lerne und verbessere mich ständig, wenn ich auf Code zurückblicke, der sogar 12 Monate alt ist, zucke ich oft zusammen. Wenn man sich Stellenanzeigen ansieht, kann man sich leicht in den Methoden und Fähigkeiten verlieren, nach denen gefragt wird. Ist es menschlich möglich, dass eine Person so viel weiß, frage ich mich oft? Eine andere Frage ist, stellen sie jemals ein Produkt her? Wird bei all dieser Planung und der Sorge um die Wiederverwendung von Code jemals etwas erledigt? Ich kenne ein Unternehmen, das akademische Entwickler anstellte, die sich so sehr auf das Design konzentrierten, dass das Unternehmen unterging, bevor ein Produkt auch nur annähernd fertig war, im Ernst! Wie viele Verzögerungen können wir den Leuten zumuten, die Testphase war dort nie ein Thema! Warum sollte das Unternehmen, das uns für ein Produkt bezahlt, für Code bezahlen, der in späteren Projekten immer wieder verwendet wird, nicht für sie?
Verstehen Sie mich nicht falsch, ich sage nicht, dass Planung schlecht ist, sie ist ein wesentlicher Teil der Systementwicklung, aber nicht der einzige Teil. Vielleicht bin ich von der alten Schule, aber der Teil, den ich genieße, ist tatsächlich das System zu schreiben und es zum Laufen zu bringen. Ok, ich weiß, dass Systeme immer größer und komplexer werden. Große Teams von Entwicklern sind die Norm. Es ist nur so, dass ich denke, dass, egal wie viel Sie planen, visualisieren und Brainstorming betreiben, immer etwas übersehen wird. Wir streben nach dem Unmöglichen, perfekten Systemen, liefern aber im schlimmsten Fall gar kein System. Glauben Sie mir nicht? Schauen Sie sich Microsoft an. Stellen Sie sich die Arbeitsstunden vor, die in die Planung einer ihrer Anwendungen fließen? Wie oft wird ein neuer Fehler oder eine Schwachstelle entdeckt? Warum wurden diese nicht in der Entwurfsphase herausgeprügelt? Dass „Vulnerability X“ überhaupt auftreten könnte, kam dem Entwicklerteam nie in den Sinn. Einfach gesagt, mit mehr als den einfachsten Systemen ist es fast unmöglich, alle Eventualitäten zu planen, egal wie logisch Sie sind. Wie kommt es, dass sie beim Testen nicht gefunden werden? Ist die Lösung hier die Entwicklung der alten Schule, weniger Zeit für Planung (Reden), mehr Zeit für Schreiben und Testen? Weniger Zeit, sich Gedanken über die Wiederverwendung von Code zu machen, mehr Zeit, dem Kunden und dem Kunden ein funktionierendes Produkt zu geben? Wäre Microsoft besser oder schlechter dran, wenn sie weniger Zeit mit der Planung und mehr Zeit mit dem Testen verbringen würden? Zu Microsofts Verteidigung: Sie sind sehr gut im Patchen, ich nehme an, sie könnten uns als Tester benutzen. Nur vielleicht, wenn sie mehr Zeit damit verbringen würden, die richtigen Tests durchzuführen, müssten wir nicht für sie testen?
Das schlimmste Beispiel für Überplanung, das mir noch begegnet ist, ist ein Finanzsystem, das ich täglich verwende. Die Implementierung dieses Systems kostete Millionen von Dollar, Jahre der Planung und wer weiß wie viele Berater. Es wurde von einem der größten Akteure der Softwarebranche geschrieben und von einem spezialisierten Softwareberatungsunternehmen angepasst. Das Endergebnis davon ist ein System, das praktisch unbrauchbar ist und nicht allzu weit davon entfernt ist, durch ein Standardprodukt ersetzt zu werden. Auf der niedrigsten Ebene ist es so schlimm, dass selbst ein falsch platzierter Mausklick die Anwendung hängen lässt. Ich kann nicht glauben, dass dieses System jemals vor der Übergabe getestet wurde. Es wurde ohnehin sehr spät geliefert, der Grund dafür war ein länger als erwarteter „Planungszyklus“. Was es tut, ist nicht so komplex, es ist nur so, dass es offensichtlich bis zu dem Punkt geplant wurde, an dem die Implementierung ein überstürztes Nachdenken war. All diese Planung hat noch nicht einmal zu einem System geführt, das die grundlegenden funktionalen Anforderungen seiner Benutzer erfüllen würde, aber heh, ich bin sicher, dass sie diesen Code irgendwann später wiederverwenden werden.
Wie auch immer, ich habe gerade ein Diplom begonnen, um zu verstehen, warum die Verwendung mehrerer verschiedener Planungsstrategien so wichtig ist. Warum in 1 Tag schreiben, was ich einen Monat lang „richtig“ machen könnte? Ich weiß, dass ich das in ein paar Jahren wieder lesen und mich fragen werde, was ich dabei gedacht habe; entweder das, oder ich sage mir „Wow, da war ich eigentlich fertig mit dem, was ich geschrieben habe“. Im Ernst, ich bin mir sicher, dass ich am Ende erkennen werde, wo ich falsch liege, in der Zwischenzeit werde ich einfach weiter Anwendungen in meinem RAD-Stil schreiben (ich bin froh, dass es einen Namen hat!). ist zwar nicht jedermanns geschmack, funktioniert bei mir aber einwandfrei.
nb Wer hätte gedacht, dass mein Entwicklungsansatz einen Namen hat, er wird als Agile Methodology klassifiziert! Hier ist ein ausgezeichneter Artikel, der erklärt agile Methoden in einigen Einzelheiten.