The most underrated book in software engineering management

Idea Flow by Janelle Arty Starr

A few years ago, while searching for ways to improve software developer productivity, I came across a book called Idea Flow by Janelle Arty Starr. It is the most underrated book on the topic of software engineering management. Since I’m late with today’s newsletter, I thought I’d promote it in this issue.

I’m a fan of the Theory of Constraints (ToC), which transformed manufacturing management in the 1980s. One important concept in ToC is the bottleneck, the resource that is constraining the process the most. Any attempt to improve the throughput of other resources won’t help your overall throughput since the bottleneck limits the throughput of the whole system. I’ve always been on the lookout for what the bottleneck is for software development on teams.

And Starr has found it. Programmers work with ideas and then express those ideas in code. They might read some code, understand the idea expressed in the code, modify the idea in their head, and then modify the code to express the new idea. According to Starr, the bottleneck is how long a programmer has the idea loaded in their head. That’s the only time they can really use their skills. If you’re struggling to load it, you loaded the wrong thing, or you are shaving a yak in order to load it, that’s all wasted time.

In the book, she describes many categories of impediments to having the idea loaded in a programmer’s head. She calls these impediments pains. Here are her ten pains, with my brief, simplified descriptions:

• Design-Fit Pain - the struggle to fit a new feature into an existing design

• Requirements Pain - difficulty understanding requirements

• Modeling Pain - difficulty understanding code

• Collaboration Pain - difficulty communicating and collaborating with others

• Experiment Pain - inefficiencies in running experiments

• Alarm Pain - friction due to testing (like flaky tests)

• Cognitive Pain - the complexity doesn’t fit into one brain

• Execution Pain - difficulty changing code

• Lack of Familiarity Pain - people new to a codebase or framework

• Disruption Pain - being interrupted during work

The essence of the prescription is that instead of focusing on software quality improvements (which is what most programmers will say their main impediments are), we should identify pains that actually occur (I spent 2 hours troubleshooting a failing test—alarm pain) and work to alleviate the pain (improve tests). In short, you tackle the concrete pains that actually come up.

In addition to contributing the important notion of the programming bottleneck, the book thoroughly critiques the technical debt metaphor, explains why retrospectives don’t work, and hypothesizes why management seems to ignore developers' pains.

Idea Flow is full of good ideas. You should read it. It really needs more attention than it’s getting. If you want a concise summary, check out this talk the author gave at YOW! 2019:

Rock on!
Eric Normand