SPF Consulting Automating Everything

Quality is Exciting, Automation is Boring. Holism and Atomicity are Crucial

Automation everywhere? On Accuracy and Correctness of Predictions

Expectations, or better: “expected results“, as we have them in functional testing, user stories, use cases or business cases, can only be applied for the checking of outcomes, where we have situations in which we know the answers to our questions. I.e., areas, where we use machines to make us faster. Arithmetics e.g., or simple business processes, where the human is underwhelmed and inaccurate and should be replaced by an automaton.

SPF Consulting Automating Everything

Automation, as it seems, is only applicable in boring fields of work.

More sensible use of digital machinery is found in predictive areas. Where we either e.g. literally want to predict the future (forecast) or understand risk (finance) or similar. Some parts of the software, however, are of predictive nature in most if not all IT solutions. It’s complicated, no, wait, complex.

Unfortunately, this is incompatible to standardized rules as wished by most administration.

There is no conveyor belt like work in the software industry.

But there is no way of knowing beforehand what a predictive instrument should deliver as an outcome, by definition. Expected results, but also our dear friends “Definition of Done“, “Acceptance Criteria“ and in the end also “User Story“ have no raison d’être in this whole area.

We need more quality – not medieval style, centralized regulation.

It is therefore of vital importance to have a solid ground, a way of not making mistakes on a base level. Atomic quality (Unit Testing) is the only way not to get combinations of complex systems producing inaccurate results in an unrecognizable way. Latter is leading to a world that accepts old and wrong results or bad practice as a reference and enables religious wars against good innovation because it is not understood. Like the legend of iron in spinach.

AI is no better.

This, of course, also holds true for machine learning, as there is no way of telling how one single weight or parameter influences the whole machine. The rising hype of “AI” called machine learning leads to even more people joining the “vernacular” programmers community. Quality is neglected all over, professional crafting is marginalized, even seen as unnecessary. If we ask data scientists about testing, the answer is „of course, we have training sets and test sets“ (-: . Expect to have more wrong statistics, fake news, crashing planes and missing target space missions.

Regression Testing is not a Save Space?

One popular attempt to alleviate the problem is to see if the built solution would have predicted the present if given the past as input. Experience as wisdom, which, in the end, also is what machine learning does. Experience, though, cannot predict the future.

Use case based functional testing without checking for outcome is not totally useless. It can reveal coverage statistics, bad exception handling and excess of runtime. But on the other hand, semi randomly generated tests can do that even better.

Yesterday’s weather.

Using the weather forecast as an example: The quality of the outcome increased over the years mainly by abstraction/extraction of better models out of the bare data and by putting sensors everywhere to get good data from micro climates in the first place. Not by having countless red regression tests in legacy software.

Commonly understood underlying models

The other crucial element for not making mistakes is speaking the same language and using a common domain to ensure the outcomes are not driven by misunderstandings and single interest drivers. Documentation is not good enough in this case. We need clear contracts.

So, now what?

Bottom line. There is no quality without unit testing and mutual theory building and good plausibility is reached with intuition and exploratory testing. It’s time to stop reading code and start to writing it better.

But I repeat myself.


Contact Information


Danilo Biella, Agile & Quality Professional



SPF Consulting AG - Insights - Teaching the Mob to students

No, we do not just learn from our mistakes!

Do we learn best from our mistakes?

Many unscientific pseudo-psychological posts from self-proclaimed coaches on social media claim that we learn best from mistakes, from our own mistakes, even. That is just not true. The attempt to move from finger pointing high-blame practice to fail-fast agile ways is sensible and lovable of course, but as always there is no simple answer to complex questions.

Why did this even come up? I have been hearing cheap ways of saying for a long time, now (“learning by burning“? Seriously?), but lately everybody seems to explain their lives with them.

Nature versus Nurture

or, it sounds better in German: Kultur gegen Natur. Culture wins. Twice. We mainly learn from patterns inferred and shown by parents, stories told by main peers and education.

The reason why humans overtook the apes in evolution is because we outsourced instincts into wisdom, wisdom that is transferred through culture, not through genes and not by making our own mistakes. That way there is space for even more culture in our heads without making the gestation period non-survivable.

Never mind the Bambi lie

That is the reason why a baby deer does not eat poisonous plants without being taught anything and human kids need to train for decades before becoming capable of surviving. Apparently there is no free lunch.

Do we really learn from mistakes?

Of course not, at least not in general. We tend to suppress negative experience in order not to be traumatized and non-functional on a long-term. And history repeats itself, we repeat the same mistakes over and over again.

A few counter examples

If we really learn from our mistakes,

  • Why do we go to work while being ill and cough all through the way there in public transport, not even months after lock-down restrictions?

  • Why do we still believe evolution needs growth?

  • Why do we believe populist harmful short-term solutions, although they never have worked?

We do learn from success

The statement that we only learn from mistakes can only be believed by people who never had success. Poor them. The same does not count for the people who spread these claims. They clearly make a profit by selling their theories to unsuccessful people. What a tragic development – that actually proves the saying wrong. Those people have learned that their success can be repeated by making weak people feel miserable in a variety of new ways by commodifying ineffective solutions.

Fail fast? Sure!

Failing fast is about making experiments in order to recognize mistakes in made assumptions as soon as possible. It is not about glorifying failure and seeking not to be successful. Trying to get away from Waterfall is important. Overdoing it doesn’t help. Simplification doesn’t help. Because, as always, there are no simple solutions to complex problems.


This is another example of everybody wanting a slice of the hype topics‘ cake without having a clue about the regarding topics. Pseudo-science on the large. If we really were only learning from mistakes, we would be degenerating already because of negative selection. Oh wait. We probably are. Happy exponential activism, everyone (-:


Contact Information


Danilo Biella, Agile & Quality Professional



SPF-Consulting AG - Insights - DevOps

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.


Felix Isensee

Felix Isensee, Software Developer