Thoughts on Software and Technology
When designing distributed systems, we sometimes think of latency and availability as two technical dimensions to balance out in our designs. I would like to argue that a more useful perspective would be to see them as two sides of the same coin. When discussing the design of a system, we typically need to carefully... Continue Reading →
The proponents of DevOps (myself included) usually bring forward arguments that evolve around breaking silos: “You build it, you run it”. This, according to the philosophy, leads to deliverables that take operational concerns into account, more automation and less finger-pointing. Many of these same arguments could also be applied to some of the other organisational... Continue Reading →
It is modern to be data-driven. Organizations brag: “We make decisions based on data.” Having spent a decent amount of time building data-crunching systems, I have a lot of sympathy for this attitude. In fact, I have suggested data-driven approaches in previous articles. But I also think that the tendency to measure and quantify everything... Continue Reading →
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 →
"Code is a liability, the functionality is an asset.” I remember finding this statement counterintuitive. Somewhere along the way it transitioned to feeling like an obvious truism. I think it’s worth spending some more words on this phrase, exploring why it is so important, and what it means for software projects. In a cognitive economy,... 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 →
A large part of the output in western economies is in immaterial or cognitive assets. Even material goods to a large part are no longer mainly valued through the physical resources that go into their production. This has created a peculiar economy in which some big players appear unbeatable. I would like to argue that... Continue Reading →
Estimation exercises that require the team to come around a table and discuss whether a task is a three or a five are a typical component of today’s software development rituals. Do the benefits of this process outweigh its cost? I have worked in teams with and without this process and I have found myself... Continue Reading →
For every hour your team spends at work, you have a choice to make: Do you spend it to add value to the product you are building, or do you spend it to improve your tools and processes that allow you to more rapidly deliver value later? This is one of the most fundamental dynamics... Continue Reading →
The Solution Space 