What Should You Optimize?

Today I want to talk about a topic every CTO needs to understand, and that’s also very useful for architects and managers.

I brought this up before here but for many people it’s still not obvious. And honestly, repeating a good point in a new wrapper probably does no harm 😁

Recently I had an argument on LinkedIn with my former colleague, who is now an architect at EPAM. I recommend reading the thread and the debate there.

Alexey describes tactics for increasing developer throughput:

• On their project, the bottleneck is user acceptance testing, which takes clients months because the process is overregulated and inefficient.

• No feature can be released until acceptance testing is complete.

• Alexey suggests using feature flags on steroids so developers can keep cranking out features instead of waiting for releases.

At first glance, it may look like Alexey came up with a brilliant optimization. He gave developers a way to keep producing even when releases are blocked.

But in reality, this optimization makes overall throughput much worse.

1. Every feature that has been built but not released is work in progress, or WIP.

2. To increase throughput, you reduce WIP, not increase it.

3. Increasing WIP in front of a bottleneck makes throughput significantly worse.
   The testers are already taking months to do their work. And now we introduce an “optimization” that increases the load on them by tens or hundreds of times.

4. By the time the feature is finally released, it may no longer even be needed.
   Apparently waiting months to release one feature wasn’t bad enough, so we turned that delay into years. And over years, even regulations change.

5. Managing WIP is expensive.
   Managing feature flags, refactoring the database, switching flags on and off, cleaning them up.

6. Bugs found during acceptance testing require rework in other features.

7. Rework becomes extremely expensive.
   Try remembering a feature you worked on a year ago. Or worse, one you didn’t build at all because the person who did already left the company.

Alright, enough boring theory. Let’s make it simple.

Why keep pumping out features into a drawer if no one will see them in production for months or even years?

So what should you do in this situation?

1. Speed up acceptance testing. In Alexey’s case, that seems unrealistic.

2. Reduce developer output, for example by significantly reducing the number of developers.

Sounds weird, right? To increase overall throughput, we actually need to reduce developer throughput 🤣
Welcome to the world of process management.

If you want to dive deeper into this topic, I recommend the classic The Goal, or the more modern repackaging The Phoenix Project + The Unicorn Project.

So, on your projects, are you reducing WIP or increasing it?