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 →
"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 →
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 →
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 think that most practitioners in the technology space will have come across a project with an incredibly skewed managers-to-doers ratio. Symptoms are typically long discussions that are detached from the on-the-ground reality, difficulties to build consensus about the right approach because of the number of opinions involved, and a way too long wish lists... Continue Reading →
The Solution Space 