Happy Friday,

I was thinking about a client of mine that is remarkable and abnormal. Something really unique about them is that they are an exception to something I almost always get on a soapbox about.

That is, you don't need to sacrifice quality for speed.

The reason I harp on this is that many groups believe that you have to cut a corner somewhere to speed up. That corner is almost always going to result in lower quality. The problem is that the speed they hoped to get is almost never worth the remediation of the quality deficit.

I can save two days by not testing my work but then spend a week fixing the bugs.

The client is an exception to this, where they took speed to an extreme. This oddly works. However, it only works if you can take it to its conclusion. So you can't have speedy development and a six-month release cycle. My client pushes code to production as soon as it's ready dozens of times a week.

What else does it take? Everything has to be small to make it fast. No big stories or features. Many small things flow all the time.

When my client works, they accept low quality through development because in the 2-3 days it takes to ship it, they will be just another day or two behind with the first set of bug fixes. In other words, the gap between initial low quality and reasonable quality is measured in days or hours sometimes.

I still maintain that even this client doesn't need to sacrifice quality to maintain this speed. In fact, I could see that this particular client spent 50-60% of their budget on bugs and hotfixes. On the one hand, the risk to the business of bad software impacting customers only lasts a day or two; on the other, they're operating at half capacity. These are tricky trade-offs.

What my client hasn't seen that I have, though, is that you can have the 1-3 day turnaround and be nearly bug-free.

So what would I tell you? Focus on building quality unless you can speed up the process to its logical conclusion throughout your entire lifecycle.

Sincerely,

Ryan