Interdependencies in your system of work, and how not to evaluate software practices

I hear of people saying their team tried Trunk-Based Development, and decided they didn’t find it beneficial after a couple of months. I’m not going to war about the benefits of Trunk-Based Development today, even if I do love this practice.

So you think you work in a team

I had a discussion on Twitter yesterday about whether a software development team should restrict the freedom of its members, and enforce shared approaches and ways of working. I and others were adamant that yes, this should absolutely be the case. Others were horrified, saying this is everything that’s wrong with our industry.

My belief system for software product development

Running a software product development company is complex. People, processes, products, technologies, and operations are all crucially important, and interdependent.

You need to identify a job people struggle with, create a product that addresses it well, price and market it appropriately, defend it against competitors, and react to market changes, all while making a profit.

Start with a skeleton not to die a zombie

Most companies die a zombie. They start lean and nimble, ship feature after feature, and delight their customers. Then, after eighteen to twenty-four months, the bubble pops, and suddenly they cannot do anything. They limp around painfully until they bite the bullet and re-write their systems, or kick the bucket.