Software Quality under the Bus

When you are not doing continuous deployment and deployment windows are limited to say twice a month, shipping valuable software features to customers is like taking the bus where the bus only stops for you twice a month. If you miss the bus, you have to wait two weeks or another month.

Given the dire consequences of missing the bus, you will do everything possible, perhaps even take every possible shortcut to ensure you will not miss the bus the next time it comes around. You would skip breakfast, not take a shower, rush out the door without kissing your wife or hugging your kids, in such a hurry you even forget to brush your teeth – yuck! The only thing you can think about in your panicked state is making that bus.

With a Lot of Busses

On the other hand if buses arrive and pickup continuously, when you needed a few more minutes to get ready, there would be no disincentive to taking the time to get ready before you go. You need a few extra minutes, no problem, you take them! Hell, you might even spend a few minutes more on extras like shining your shoes or double checking that nothing had been missed. Or go wild and add a little something to make yourself stand out.


But if the city budget is never going to allow for a continuous bus schedule, another option you might want to try is Uber! Instead of getting ready to make a delivery schedule, schedule the delivery when you are ready. Uberize the process!

The idea here is for the deployment countdown to begin after the delivery team has signed off on the feature set for final Qa certification and production deployment. The deployment date would be determined by the date when the software is ready for deployment.

This approach has a few advantages.

Quality. Scheduling delivery when the goods are ready means no more need for shortcuts, assuming quality and completeness would be the first order of business under the right conditions.

Time to market. No time is wasted waiting for a deployment window because the deployment mechanism kicks off immediately once the software is completed.

The Uber model also has a disadvantage when you have many projects in concurrent development, and would be particularly problematic if there is concurrent development of the same components on different components in different environments.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s