“We only learn through failure. This quote attributed to the legendary alpinist Reinhold Messner holds a lot of truth in it. Modern organizations like to talk about good failure culture, but is a failure in every circumstance a good thing? Probably not. As a software engineer and climber, I saw a few failures with sometimes quite drastic consequences. Failure is never the goal but sometimes unavoidable, so how can we as individuals, teams, and companies benefit from it?
What is your organizations currency of getting things done? When trying to getting things outside daily business done, every organization reacts to different kind of arguments and incentives. “Paying” in the right kind of arguments is often the key to get ones concerns put into action.
99.9% der Softwarefehler werden von Programmierer verursacht. Testen und Code Reviews helfen zwar, sind aber nicht immer genug. Viel schöner wäre es, wenn ich als Programmierer eine falsche Verwendung meines Codes von vornherein Abfangen könnte. Mit “Design by Contract” kriegen wir Softwareingenieure ein Werkzeug für genau diesen Zweck in die Hände. Programmcode wird durch “Design by Contract” aber nicht nur korrekter, sondern auch lesbarer und somit wartbarer. Und nicht zuletzt wird mit diesem Werkzeug Code auch robuster gegenüber Regressionsfehler. Einige Programmiersprachen kennen das Konzept bereits als natürliche Spracheigenschaft1, aber auch wenn dies nicht der Fall ist, lässt sich die Unterstützung für “Contracts” leicht einbauen.
CMake can be hard to figure out. I love CMake, but unfortunately, its documentation is more focused on completeness than on providing hands-on-examples. Since I found it hard to find a comprehensive example of how a header-only library can be set up, I decided to provide an example of a CMakeLists.txt file for such a library here and analyze it line by line. The example is taken from SI, a header-only library that provides strongly typed physical units. In order to keep the CMake file as small as possible, a few possible optimizations are omitted. Notably, I stripped any information relating to testing out of the project.
Are modern organizations ready to pay the price for increased demand for their leaders? Countless companies and organizations are currently changing how they work internally. Some experience a growth spurt in the wake of digitalization, others want to be more flexible in reacting to change. And a lot of these organizations struggle with these transformations. They got the agile framework of their choosing in place, they got the teams set up and maybe they even streamlined their portfolio and technological infrastructure. At first, everything looks good, but after a while, all the shiny new things start to lose their gleam and things become tedious again. Decisions take ages to be put into action and once a course is set, people find it hard to deviate from it. All the fluffy stuff like empowerment of the teams and people somehow does not seem to happen. These symptoms might hint that an organization is suffering from “leadership debt”.
Scrum is hard and tedious! It’s like groundhog day for software projects! Ever noticed that scrum does the same thing over and over again? Plannings, retrospectives, dailies, backlog refinements… Each sprint we do the same thing! Especially for long running projects this becomes boring. Programmers follow the Don’t repeat yourself paradigm, so why we do differently in processes? There has to be room to optimize, right? There is a solution to it: Scaled Single Sprint Scrum - It’s like scrum but totally different!
SAFe is the worst implementation of “corporate agile” that is out there! Over the last few months I heard this sentence or a variety of it a few times. There is some truth to it, but it is not the whole truth. The SAFe-framework is far away from what I imagine when thinking “agile”, but there are some aspects which are pretty neat. Despite all the critics it is a very popular framework that is implemented in a lot of bigger companies. So there has to be something good in it, doesn’t it? Let’s have a more differentiated look at it!
A good product vision is the cornerstone for being successful at delivering software products1. Having a product vision that is tangible and accepted by your developers is one of the most important things to have, if teams are supposed to work in an empowered and self-organized way. A vision is not just a good advertising tool, but it is the foundation to creating a purpose for everyone’s alignment towards what the product shall be. It is a common pattern, that companies that struggle with creating good product or company visions, find it very hard to create alignment and motivation in those employees who are building and delivering their products.
-
Actually this is true for any product in development, not just software. ↩
Most hobby projects die at the idea stage - Mine do not. A while ago I decided to revive an old idea of mine to implement the International System of Units as a strongly typed C++ library. In order to try to bring this project forward I tried an experiment: I would make at least one commit each workday for a month. A month later I am somewhat proud to say, that I kept this promise to myself with only one “comittless” day. But how does my pet project look now?
How good are your decisions? - Every day we decide a lot of things small and big. At work or any professional setting we often have clear deciders. This can be a senior subject matter expert, the traditional “boss” or some collaborative process in an empowered team - it does not really matter. Contrary to our private live, in business we often have to make decisions more explicit and documented, for instance in the form of meeting minutes. Some people are good at deciding, others find it very hard.