Heute gehen wir mal ganz weit zurück und zwar ins Jahr 1980. Da war ich gerade 10 und aus den Erzählungen, die ich im Studium von Professoren hörte, muss man da noch mit Lochkarten gearbeitet haben 😉
In diesem Jahr veröffentlichte M. Lehmann einen Artikel mit dem Titel „Programs, Life Cycles, and Laws of Software Evolution“. Wir haben den Artikel Anfang der 1990er Jahre im Informatik-Studium behandelt und er hat mich damals tief beeindruckt.
Lehman unterscheidet drei Typen von Computer-Programmen: S, P und E.
- S-Programme sind sogenannte Spezifikationsprogramme. Sie beruhen auf einer exakten Spezifikation dessen, was zu tun ist. Spezifikationen haben vollständig, korrekt und widerspruchsfrei zu sein. Man kann also beweisen, dass die Spezifikation korrekt ist und auch, ob das Programm der Spezifikation entspricht. Coole Nummer. Funktioniert z.B. für das 8-Damen-Problem, die Türme von Hanoi etc. Solche Programme kann man einmal schreiben und muss sie danach nicht mehr verändern (allenfalls zur Performance-Optimierung).
- P-Programme lösen Real World Problems, z.B. Wettervorhersage, Schachprogramm etc. Auch hier lässt sich eine Spezifikation erstellen, aber das Problem lässt sich nicht vollständig lösen. Man kann beim Schachprogramm nicht alle möglichen Zugkonstellationen durchrechnen und beim Wetter nicht jedes Luftmolekül simulieren. Man muss Heuristiken anwenden und kann vorher nicht sicher sagen, welche erfolgreich sein werden. Die Qualität des Programms ergibt sich also nicht daraus, dass es sich konform zur Spezifikation verhält, sondern durch Vergleich seines Ergebnissen mit der realen Welt. Sind die Ergebnisse des Programms nützlich?
- E-Programme sind Embedded Programs – nicht eingebettet in Hardware, sondern in die Welt, die sie modellieren. Typische Beispiele sind Systeme zur Unterstützung des Sachbearbeitung aber auch die meisten Webseiten und Smartphone-Apps, die wir ständig benutzen. Sie verändern die Art und Weise, wie wir unsere Arbeit verrichten oder unser Leben leben. Und damit verändert sich der Kontext, aus dem die Anforderungen für das Programm mal entstanden ist.
Uns so landet man für E-Programme bei iterativer Entwicklung statt Wasserfall.
E-Programme und KI-Coding
Ich lese immer wieder, dass KI-Coding agile Vorgehensweisen obsolet machen würde. Das verkennt aus meiner Sicht vollkommen, warum wir iterativ (und später agil) entwickeln: nicht, weil das Codieren so schwierig ist, sondern weil wir vorab nicht sagen können, wie genau das Programm aussehen muss.
Und das ändert sich nicht, selbst wenn die KI die komplette Programmierung übernehmen könnte.
Über den Autoren
„Wir müssen immer wieder das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse
E-Mail: stefan.roock@it-agile.de
LinkedIn: https://www.linkedin.com/in/StefanRoock/
Mein Name ist Stefan Roock und ich will eine bessere Arbeitswelt schaffen; eine in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben, Unternehmen erfolgreich sind und sich verantwortlich in der Gesellschaft verhalten. Ich helfe Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfesseln.
Ich verbreite und entwickle seit 1999 neue Arbeits- und Organisationsansätze in Deutschland. Das habe ich zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner getan. Ich habe seitdem mein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Besondere Produkte entstehen nicht dadurch, dass Teams „agil“ Anforderungen umsetzen. Stattdessen müssen Teams gemeinsam im direkten Kundenkontakt Produkte und Services gestalten.
Auf diesem Weg habe ich unter anderem die it-agile GmbH mitgegründet.