Thoughts on Software and Technology
"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 →
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 →
I have hard people in big technology companies pitch their workplace as being “like a startup”. To me this always seemed like a strange pitch, your big company likely cannot offer the most positive aspects of a startup environment. It might have some of the negative ones, though, which is not a great selling point.... Continue Reading →
The Solution Space 