Thoughts on Software and Technology
If we had to write a list of typical skills we expect of Software Engineers, “writing clean code” would probably be on it. However, the trouble with clean code is that it is hardly an objective measure. I don't think I've ever worked in a team where everyone had the same understanding of what it... Continue Reading →
In this article, I want to explore a strategy of dependency management that enables transitive dependencies to evolve independently and to disentangle the gnarly problem of conflicting transitive dependencies. Dependency hell is a real place. The times I am struggling trying to find a matching set of dependencies are moments in which I ask myself... Continue Reading →
Cutting up large systems into smaller components is one typical task of software architecture. Many modern architectures follow a (micro-) service pattern which is one particular family of strategies to decompose a larger system into smaller parts. It would be short-sighted to apply any such method without consideration of its respective strengths and weaknesses and... Continue Reading →
In “Good Strategy / Bad Strategy”, Richard Rumelt provides a framework for strategic thinking. I found that the ideas from his book also translate to the design of software systems: The key is to have a good sense of the relative strengths and weaknesses of your current position and to apply coherent design decisions. Analysis... Continue Reading →
I have talked about how software architecture design is a way of constraining the solution space for a project. Here is another angle on this: Any attempt to design a software architecture is an exercise in predicting the future. The usual way to make predictions is to extrapolate data from the past. This is based... Continue Reading →
Like with any kind of data, to fully understand the map data design space, we need to understand both the way it is used from a consumer perspective and the way that it is produced. Understanding the different requirements of producers and consumers leads to a better understanding of the solution space and the design... Continue Reading →
The term “Software Architecture” can evoke the impression that it describes a blueprint that needs to be completed before actual development work can start. This association is natural given the origin of the term: The architecture of a building better be complete before the construction begins. Unfortunately, this vision is also at odds with what... Continue Reading →
When making technology choices, most of us have to learn the hard way that almost every single decision we take comes with a trade-off. Most of the time technology choice A will have some advantage over technology choice B and vice versa. Very rarely a choice will turn out to be “Pareto-dominant”, meaning superior along... Continue Reading →
It almost seems like a rite of passage: Every company sooner or later discovers they need to build a “platform”. The idea is simple: If you find the common denominator behind the company's development activities, you can build the tooling that allows future projects to be more cost-effective provided they make use of the same... Continue Reading →
I have become increasingly interested in understanding why it is so common for softwares projects to end up in the famous “Big Ball of Mud”, a state in which the incidental complexity of a system reaches a point that makes every small modification extremely painful. Only once we understand the reasons we can design strategies... Continue Reading →
The Solution Space 