Thoughts on Software and Technology
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 →
"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 →
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 →
Office politics are one of these topics that no one wants to talk about. I’ve met people claiming that in their organization, politics do not exist. Others lament that politics are the root of all evil in their workplace. I think that politics are maybe sometimes unpleasant, especially when they negatively impact your work, but... Continue Reading →
I have noticed a fairly anecdotal negative correlation between the effectiveness of the interactions between a product manager and the engineering team and the frequency with which either party uses the phrase “gathering requirements”. As I am generally curious about how language determines our understanding of the process of software development, I would like to... Continue Reading →
The Solution Space 