Code is a Liability

"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 the System

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 →

The Acceleration Game

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 →

Good Systems / Bad Systems

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 →

Game Theory and Office Politics: Coalitions

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 →

Gathering Requirements

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 →

Blog at WordPress.com.

Up ↑