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 - Insight - DevOps ist keine Pipeline

DevOps ist keine Pipeline

DevOps ist keine Pipeline. DevOps ist eine Arbeitsweise.

Der grundlegende Gedanke hinter DevOps ist das gemeinsame Verwalten aller Aspekte in der Entwicklung durch alle Mitwirkenden. Im Gegensatz dazu sind herkömmliche Entwicklung- und Betriebsabteilungen organisatorisch getrennt, folgen unterschiedlichen Zielsetzungen und es bestehen zusätzlich technische Schnittstellen. Das Einbinden der operativen Aspekte in den Entwicklungsprozess minimiert das Projektrisiko, es ermöglicht, effizient und schnell Änderungen für den Kunden freizuschalten und somit Mehrwert zu generieren. Continuous Integration und Continuous Delivery sind dabei nur Teilaspekte.

SPF-Consulting AG - Insights - DevOps

Die Entwicklung, die Dokumentation, die Quelltext-Administration, die Versionierung, die Ausführung von Tests, das richtige Verpacken bis hin zum Ausliefern auf einen in der “Definition of Done“ definierten Grad, sind alles Teile von DevOps, welches vom Team selbst und als Ganzes verwaltet wird.

Auch wenn de facto die Präferenzen und Ausprägungen innerhalb des Teams verschieden sind, soll doch jede Person die Aspekte kennen und alle Teilbereiche eigenständig ändern, ausführen und betreiben können.

Alle Artefakte, die zum Projekt gehören, also auch, wie sich das Produkt in die Pipeline integriert (z.B. Helm, Docker, Jenkins-Konfigurationen) sind dabei im selben Projekt im Version Control System (VCS, z.B. Git). Everything as Code. Everything is Code.

Das Zusammenspiel des VCS mit der Pipeline ist dabei essenziell. So können zu jedem Zeitpunkt, auch bei noch in der Fertigung stehenden Teilen, Aspekte kontrolliert und deren Konsistenz garantiert werden. Aufgaben mit unbekanntem Aufwand, also typischerweise, neue, Cloud spezifische Aspekte, sollen von Anfang der Entwicklung angegangen werden (Shift Left), später geht man Risiken ein, es wird entweder nicht mit der nötigen Sorgfalt gearbeitet (Technical Debt) oder gar durch fehlendes Know-how viel später durch Spezialisten von aussen. Dies hat kostspielige Folgen wie Verzögerung, Behinderung anderer Projekte und Produktionsstop.

Bereits beim Entscheiden über die Entwicklungszweige übt man Einfluss auf die Pipeline aus, die über alle Versionen die Einhaltung von Qualitätsvorgaben prüft (Quality Gates). Das automatische Verpacken und Parametrieren der verschiedenen Versionen bis hin zur automatischen Generierung von Releasenotes vermeiden Fehler im Prozess. Lang laufende Tests können, je nach Aufwand, nachgelagert sein oder periodisch starten und die Pipeline validieren.

Integrative und manuelle Prozesse, wie das Ausliefern in Staging oder produktions(nahe) Umgebungen oder Operationen an Live-Systemen werden, wo immer möglich, durch die Pipeline unterstützt. Hier finden sich Shift-Right Themen wie Deployment by Feature, Blue-green Deployment, Stress und Performance Tests, E2E Testing, Chaos Testing, Monitoring und Reporting wieder, aber auch Exploratory und Mob Testing. Dies liefert ein Mass für die „Gesundheit“ und Flexibilität des Systems.

Entgegen der landläufigen Meinung ist DevOps also nicht das Errichten einer Pipeline, die von dedizierten Spezialisten gehandhabt wird, sondern die Grundlage für die Zusammenarbeit in agilen, selbst organisierten, cross-functional Teams. Hierfür müssen in den Organisationen strukturelle Änderungen vorgenommen und Räume geschaffen werden.

Wenn du nicht sicher bist wie DevOps in deinem Umfeld umgesetzt ist, dann lass uns darüber sprechen.


SPF Consulting AG - Danilo Biella - Agile & Quality Professional

Danilo Biella, Agile & Quality Professional