Beiträge

SPF-Consulting AG - Insights - Komplexität

Komplexität – Code hat keinen Wert

Komplexität – Code hat keinen Wert – wenn es niemanden gibt, der ihn versteht.

Komplexität in Softwareprojekten ist unausweichlich und seit jeher ein immer grösser werdendes Problem. Doch warum ist die Komplexität ein solches Problem und was gibt es für Ideen damit umzugehen?

SPF-Consulting AG - Insights - Komplexität

Wenn wir uns den Prozess des Programmierens vorstellen, denken wir verständlicher Weise direkt an den Akt des Codeschreibens selbst. Während dies einen Grossteil der Arbeit ausmacht, so ist dies jedoch bei weitem nicht das ganze Bild. Bevor Code geschrieben wird, entsteht unvermeidbar ein mal mehr, mal weniger klares mentales Modell von Requirements, Constraints, Abläufen und Fallstricken im Kopf des Programmierers existieren, welches ihm ermöglicht den entsprechend bestmöglichen Code zu schreiben.

Ein Problem mit diesem mentalen Modell ist jedoch häufig das es zum Grossteil lediglich in den Köpfen der Programmierer selbst lebt und sich dort weiterentwickelt. Wenn diese Programmierer dann das Projekt verlassen, kann das oft zu Problemen führen. Knowhow geht verloren, technische Visionen verblassen, geheime Handgriffe, die die Maschinerie am Laufen lassen geraten in Vergessenheit. Neue Programmierer, die in das Projekt dazustossen, müssen möglichst viel von diesem mentalen Modell aufnehmen und verstehen. Tun sie das nicht oder nur teilweise, oftmals ein Folge von suboptimalen Know-How Transfer, besteht die Gefahr das neu geschriebener Code nicht in die bestehende Code Base passt und zu Qualitäts- und Wartungsproblemen führt.

Abhilfen dafür existieren selbstverständlich, allem voran eine gute Dokumentation, ob im Code selbst oder anderweitig, sowie eine ausgebaute Testsuite. Eine «Silver Bullet» ist hier aber schwer zu finden. Dokumentation entsteht oft after the fact, kann lückenhaft sein oder nicht mehr aktuell. Tests helfen das Vertrauen in die Funktionalität und Qualität des geschriebenen Codes zu erhalten, sind aber ebenso Teil des Codes und somit auch des mentalen Modells. Sprich man kann die Tests nicht verstehen wenn man nicht das Modell hinter dem Programm verstanden hat.

Eine bereits erprobte Idee wäre es also, den Programmierungsprozess auf der Artefakt-Ebene nicht zu unterteilen in Dokumentation und Requirements auf der einen Seite und Code auf der anderen Seite, sondern diese beiden Aspekte direkt miteinander zu verheiraten. Hierbei gibt es schon eine ganze Reihe an Ideen und Versuchen dies zu realisieren. Generell dreht sich der Ansatz aber oft um die Definition einer gemeinsamen Sprache zur Beschreibung des Modells. Nicht selten ist diese Sprache dann Teil des Codes selbst. Bestehender Code wird damit erweitert um Contracts und Constraints des Modells selbst nicht nur zu dokumentieren, sondern auch direkt vom z.B. Compiler verifizieren und validieren zu lassen.

Ein Nachteil dieser eher codebasierten Lösungen ist jedoch die damit zusammenhängende Komplexität. Das Lernen und korrekte Anwenden dieser neuen Modell-Sprache erfordert Zeit und ein hohes Mass an Konzentration. So entstandene Artefakte sind schwierig bis unmöglich für Unwissende zu verstehen und zu erweitern. Auf der Suche nach einem Weg der Komplexität Herr zu werden hat man so noch mehr Komplexität geschaffen. In gewissen Kontexten kann dies funktionieren, in vielen anderen kann es aber auch katastrophal scheitern.

Eine natürliche Schlussfolgerung daraus ist natürlich, nicht eine text-basierte Sprache zu verwenden, sondern sich möglichst and Bildsprachen zu orientieren. Auch hier gibt es bereits einige Versuche, oftmals schiessen diese Lösungen aber etwas über das Ziel hinaus und zu viel des auszuführenden Codes wird generiert. Dies macht es zum einen wieder umso komplexer, je mehr man mit der Bildsprache ausdrücken will, als auch macht es die Arbeit der Programmierer wiederrum nicht unwesentlich anstrengender. Mit zu viel generierten Code auf Dauer interfacen zu müssen macht den Entwicklungsprozess auf mehrere Arten unangenehm und langsam.

Was wäre also, wenn man aus den Fehlern der vorhergegangenen Lösungen lernt und einen neuen Vorstoss wagt. Somit keine neue Sprache schaffen, dessen Grammatik und Syntax erst aufwendig einstudiert werden muss, sondern auf simple und bekannte Graphiken wie UML setzten. Anstatt No-Code-mässig versuchen, den gesamten Programmierprozess zu abstrahieren, lieber auf kleine und contract-basierte Generierungen setzten, mit denen ein Entwickler dann simpel interagieren kann. Mit wenig Aufwand könnte hier einiges geschaffen werden, lediglich versuchen müsste man es.

Autor

Felix Isensee

Felix Isensee, Software Developer

E-Mail: felix.isensee@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/fisensee/

 

 

SPF Consulting AG - Insights - Teaching the Mob to students

Teaching the Mob to students

Teaching the Mob to students?

When Bernhard Wagner – acting teacher at ZHAW and teaching the ways of programming to students of electric engineering – asked me whether I could imagine using the Mob Programming & Test Driven Development approach to programming in a didactic setting and if I’d be willing repeat my workshop on “The MOB & TDD” for his class, I was pleasantly surprised and replied “There is nothing I’d rather do”.

SPF Consulting AG - Insights - Teaching the Mob to students

Is it just about collaboration?

His concern was that individuals would be left behind unnoticed so he would not be able to help them catching up. Putting in place any kind of swarming culture would be beneficial to avoid this problem. And of course, the mob the merrier. Less knowledgeable people and introverts can profit from the team effort by developing their own skills.

But the advantage for the pros and extroverts is very valuable, too, not only for the team as such. Teaming up properly leaves space for the driving forces to learn about new ideas in areas from which fellows think they have nothing left to learn about. This is not only true for study groups. Applying these principles in professional teams is the easiest and most effective way to literally foster every single agile value.

But does it make a good case?

Suddenly a doubt rushed through my mind: Isn’t everybody already saying that ensemble programming only works in academic examples? How is this going to help? But nothing of that happened. Au contraire. The not-yet professionals came up with the same arguments as team leads normally do, but much quicker, how that would not work out out in the field as everyone would think that you lose capacity by working in groups. They were quickly to be proven wrong and be convinced. It is left to the inclined reader to look up the facts from other articles, where these overly simplistic arithmetical arguments are proven incorrect.

At the end of the day

Since the class was too large, we had to split into two groups and do the exercise twice. When the first group left the room and the second came in, one of the entering students said: “You erased the fatalistic look of indifference from their faces, what did you do?!?”. Guilty as charged.

After all was over, I asked for collecting feedback and in the end we got only positive if not effusive reactions.

What is the lesson?

After 2 generations of computer science in schools we’re still trying to teach if-else, while, algorithms and patterns, instead of putting quality driven work and collaboration first. We need to change that if we want to improve culture.

 

Contact Information

 

Danilo Biella, Agile & Quality Professional

Email: danilo.biella@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/danilo-biella/