Systemic Software Engineering

Systemic Software Engineering is an approach to software engineering. That is, creating value and solving problems using software solutions.

The system is alive. Connected, running and distributed

Programming is only one of the many interaction modes of the system

Humans are part of the system. Politics, Economics and Emotions are everywhere

Nothing is certain. Everything is broken and everyone is wrong

Systemic Software Engineering poses these observations as facts. If these facts resonate with you Systemic Software Engineering should pose a coherent model for working effectively with software. The contribution of Systemic Software Engineering is primarily and aggregation and relation between already established principles, practices and concepts and as such parts can be taken and used individually, though we believe it works best as a full package solution.

The purpose of Systemic Software Engineering

As a completely unfounded statement I truly believe that we as an industry suck at making software. Yet look at all the magnificent things we build. I attribute some of this to the inherent difficulty of making software, but a large source of our challenges comes from the way we work and think about software. All across the organizational chart, from the individual contributors to the c-suite mental models are wrong and we keep creating friction. Making good software is hard enough without us increasing the difficulty.

One of the issues I have with current models are that they tend to be polarized on how concrete or prescriptive they are. Models like SAFe and Scrum are extremely explicit in what they expect you to do when. This makes them easy to adopt, yet can result in pushback due to the dogmatic approach. And worse, while these prescriptive setups can be considered sound vantage points, it does not create a healthy environment that builds mastery or fluency in agile. Rather, it builds mastery of itself. That system becomes self-perpetuating. On the other hand, other frameworks or models are abstract and vague. How do you follow the agile manifesto, or apply CALMS? These models require much more from the adopters. If you succeed in applying them, you will be better at evolving and building both your skills and your products. However, it is difficult to do so, and that may be part of the desire to go for more prescriptive setups. Simultaneously, if you do not know where to start, and have a blank slate it can be overwhelming, which again leads towards adoption of prescriptive setups. The problem is that these prescriptive setups does in themselves lead to adopting more descriptive approaches.

So Systemic Software Engineering tries to be a few things.

An adaptive model for software engineering

Based on the core observations above, Systemic Software Engineering strives provide prescriptive practices, that will most likely help you improve your software engineering capabilities. This ensures that Systemic Software Engineering will be deployable in any engineering organization

A meta-system for thinking about software engineering

Included with the prescriptive model for adopting Systemic Software Engineering is the principles, practices and mental models for how, and why we arrived at the current state. The goal is that Systemic Software Engineering enables organizations to grow beyond Systemic Software Engineering. Ideally, Systemic Software Engineering should be self-replacing as the principles should survive over time while implementations change, but it is a design goal in itself that Systemic Software Engineering builds the momentum that teams and organizations can use to evolve beyond.

A self-consistent model

A model that you can use to reflect upon and to form opinions based on. While Systemic Software Engineering is intended to be universally applicable, different values and principles may go against it. It is however easier to figure out what your principles are if you have something stress test them against. Systemic Software Engineering tries to never say “It depends”, and have an opinion instead. The opinion is not considered irrefutable fact, but an opinion is better than none.

Why?

Truth be told. Systemic Software Engineering is a thinking tool for me. It represents my understanding, mental model, opinions and feelings about software engineering. I hope it contributes to making the industry a bit better. And getting feedback on the model is how we grow and learn.