People always jump to “optimize cycle time and throughput of development” as if programming were the bottleneck. So far, when I’ve measured, it has not been. Usually programming is a small component of lead time, but easy to blame.

And in most cases, if the programmers rushed to “clear their plate” ... even if they were 4x as fast at that... it would not have any real effect on lead time.

In most cases, if the programmer spent twice as much time programming carefully they would be 10% to 30% faster going to market. Sometimes even 4x or 5x.

If programmers spend 80% of their (non-meeting) time working on defects now, then they could eventually be easily 2x faster by going carefully at half-speed. Let that sink in.

What tends to be slow are round-trips to QA and review. Those are horribly slow. In some shops, code cycles between dev 3 times on average; with a cycle taking 2-5 days.

Queuing up for reviews (yes, even PRs) in some shops can delay a feature 3-5 days. Even if it took just 2 days to write it.

And then you have work that *was* done, *was* tested, *was* reviewed, and then sat in a branch for weeks until it could not be gracefully and accurately merged into a release.

Of course, merging a bunch of features together creates a unique new version of code which has never been tested before. More release delay. Important, because big merges are more high-risk than small merges; bad things happen.

And of course, developers spend 1/5 of their time in meetings. Many of these are status meetings and estimating meetings and meetings to listen to someone explain why they need to go faster.
Some are HR.

And then there is the task-switching costs; some shops average 5 open tickets per developer. Have you ever tried to program five things at once? You can’t of course, but you’re trying to pay attention to 5 things at once.

Add on the 10:30am and 3:00pm slumps where developers have been conscientiously sitting at the keyboard for hours without taking a break and all the blood has settled in their legs. So they “gut through” for several more hours.

Did I say programmers? Pardon me. I mean team members. Testers, programmers, UX, etc. Everyone so conscientious about being busy at the keyboard all alone all the time; not wanting to be seen not typing. Bless their hearts.

Contrast: Consider lean principles (measure and improve at bottlenecks), working in teams to spot and mitigate errors, and cut WIP way down. If we saw how we worked, we’d probably make it better. But we have to stop heads-down pounding to do that.

But do you know what happens when you optimize a non-bottleneck? Yep. It makes your problems worse.