Dominik Berner

“NoEstimates cannot work because people want to plan ahead.” Sounds familiar? Actually NoEstimates means does not mean the absence of any forecasting and planning ahead. Quite the contrary. By tracking the throughput of a team and having a lean development process planning can actually become more reliable, despite not estimating a single story.

99.9% of software bugs are caused by programmer mistakes. Testing and code reviews help, but are not enough. If bad code could be caught even earlier, that would be so much nicer. With Design by contract we software engineers get a tool that does exactly that. Design by Contract not just makes code more correct, it also makes it more readable and much more robust against regression bugs.

Breaking down stories in small, manageable chunks is an essential skill when maintaining a good backlog. Sounds good, but how does one actually do the slicing? Splitting backlog items is not magic, but a skill that can be learned. All it needs is a bit of thinking and a few techniques to get going.

How does remote teamwork actually work? Working together remotely has its challenges, but they are not as big as one might think from the cozy office of a co-located team. While the communication bandwidth of physical face-to-face communication still beats everything else, but modern technology and a few rules for online behavior can make up for a lot.

Change is everywhere in modern organizations. Those organizations that find it easy to change succeed, the others suffer. Life in modern companies is signified by fast and frequent changes. Be it agile transformations, digitalization, new tools, new technology, new methods, new processes (and much more) - there are are many powerful drivers for change in a modern VUCA-World The stories of painful and failed change are abundant, yet there are organizations that successfully change frequently without all the pain. What makes their changes much more likely to succeed? And how make they change appear easy? Together with colleagues at bbv Software Services we dove into the topic and we came up with seven major factors that contribute to successful and lightweight change.

A good part of leadership is to bring inspiration and purpose to people in order to motivate them do get things done. In modern companies job no longer falls to a single boss-leader, but situational, decentralized leadership is the way to go. In essence “whoever knows best” leads the way. In the book Start with Why and a TED talk, the author Simon Sinek describes what he calls the “golden circle” as a model to create purpose and inspiration. In the tiniest nutshell the method consists of three concentric rings, “Why” (innermost), “How” and “What” (outermost) and these questions get answered inside out.

“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 Spracheigenschaft¹, 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.