Michele on Software

We used to build products.

One of the things I keep thinking about is the extent to which most companies go out of their way to discourage their own employees from tackling the problems they spot.

Hey there, reader.

Today marks my son’s first birthday, a milestone that sneaks up on you with its quiet weight.

Every morning, I drag myself to the sink, razor in hand, steam curling like a ghost around the fogged glass.

Today, I want to share my concerns about a trend I’ve noticed in many companies: jumping to agreement too quickly when debating solutions.

Kent Beck’s timeless advice, “Make the change easy, and then make the easy change,” is a guiding principle for software craftsmanship.

The Search for a Better Term Over the years, leading teams and advising executives, I’ve often used “technical debt” to describe those persistent issues that slow us down or make changes risky.

I wonder whether AI can enable a dual track model for building products while finding product market fit.

If you’ve worked with software for any length of time, you’ve seen it: a codebase that starts as a lean, focused system can morph into a costly, resistant beast without careful stewardship.

In my journey through various workplaces, I’ve noticed recurring problems that seem to plague most companies.

Hype cycles in tech rarely translate to significant changes in our lifestyle.

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 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.

Running a software product development company is complex.

Most companies die a zombie.

I often rant about what I feel is wrong with an approach, practice, or system.

These days we’re dealing with a job burnout epidemic.

The popular model Software product companies aren’t usually started by people with a strong background in building software products.

The situation An obsession with competitors Most startups obsess over their competitors.

The ubiquitous way of structuring companies is by nesting areas of responsibility.

Metrics and indicators are amazing when used appropriately.

“Make the change easy, then make the easy change”.

REST is still going strong these days, with many companies structuring their HTTP API based on its principles.

We always hear that software development is hard, and that a very high percentage of all software projects fail.

Stop writing unit tests!

The controversy about developer productivity There’s been a lot of controversy recently about developer productivity.

The evergreen problem-solving If you work in software product development like me, you hear a lot about problem-solving.

Test-Driven Development (TDD) is arguably one of the most polarizing and misunderstood approaches in software development.

Why are we talking about modules?

“This year we want to double the number of developers!”

“This quarter we want revenue up by 10%” - but is it really that simple?

Companies always talk about wanting to hire A players and great talent.

We often use different words for what we know, like in data-engineering, information systems, and knowledge workers.

I’m sure you have encountered plenty of toxic people at work.

Understanding models and lenses, their applicability, and their limitations.

I can hear the what’s in it for me?