DevOps: Quantity over Quality

Last updated by UpGuard on November 20, 2019

scroll down

Quality over QuantityMy mom used to tell me 'quality over quantity' back in high school when I was dating girls. Of course that meant that I completely ignored her and would date a girl if she was breathing. What in the hell would you expect an awkward 17 year old boy to do?! I've heard that same sentence used in lots of other ways too: when writing, when speaking, when eating, when working out, and so on. What does that have to do with DevOps? As I continue on my journey through the DevOps movement, it seems to me that we have a bit of a conflict here - the goal is to release at a higher velocity (quantity) with well tested code (quality). Is this really possible? I know that some of the 'high-performers' like Amazon, Etsy, Flickr and Netflix are proving that it can be accomplished, but I keep wondering if slowing down can actually help us deliver more extraordinary things.

Why Quantity Should Be Your Priority

Quantity should be a higher priority than quality, because it leads to higher quality. The shorter path to maximized quality is in maximized quantity, and executing on the feedback after each finished product. Consider a basketball player like Kobe Bryant who when developing his jump shot, would spend his offseason making 2,000 shots a day. Not taking. Making. Here is another interesting case for quantity - as David Bayles and Ted Orland write in Art and Fear:

The ceramics teacher announced on opening day that he was dividing the class into two groups. All those on the left side of the studio, he said, would be graded solely on the quantity of work they produced, all those on the right solely on its quality. His procedure was simple: on the final day of class he would bring in his bathroom scales and weigh the work of the “quantity” group: 50 pounds of pots rated an “A”, 40 pounds a “B”, and so on. Those being graded on “quality”, however, needed to produce only one pot — albeit a perfect one — to get an “A”. Well, come grading time and a curious fact emerged: the works of highest quality were all produced by the group being graded for quantity. It seems that while the “quantity” group was busily churning out piles of work—and learning from their mistakes — the “quality” group had sat theorizing about perfection, and in the end had little more to show for their efforts than grandiose theories and a pile of dead clay.

The lesson we all can learn here is don’t get stuck trying to get it right the first time. Instead, start making one or two things everyday.

Why Quality Should Be Your Priority

It's easy to get caught up in the numbers game: 1 deployment a day, 2, 10, 100....but the reality is that you don't need these to be successful. If you aren't delivering real business value and solving customer problems, why bother? Crafting single high quality products tends to be expensive and time consuming, and can prevent you from being responsive to changing market conditions. However, you shouldn’t overlook the importance of quality over quantity. Let’s take a look at an example where quality over quantity has prevailed:

In the auto industry, BMW’s business model of selling well-crafted luxury cars in tiers has become a standard for companies wishing to emphasize product quality. BMW offers its flagship vehicles in three flavors – the compact 3 series, the mid-size 5-series and luxury 7-series – all aimed at different markets. In addition, it sells sporty Mini hatchbacks as well as the ultra-luxurious Rolls-Royce in order to appeal to the lower and higher ends of the pricing spectrum, respectively. BMW’s clear separation of its tiers, all while retaining an aura of overall luxury, was the inspiration for Steve Jobs when he returned to Apple in the late 1990s. At Apple, Jobs mimicked BMW’s tiered pricing system with his computer and iPod lines. BMW and Apple are shining examples that offering a quality product on multiple pricing levels can attract the maximize amount of customers at premium prices.

If your product becomes known for its shoddy construction – and due to the Internet, word travels fast – your overall sales will be quickly damaged. Favoring quality over quantity will increase your company’s reputation and increase product loyalty, which will keep your business sustainable in the long run.

I'm not sure there is a right answer and the ideal one is "I want both", but I wonder if it's better slow down and deliver higher quality products or deliver faster to be responsive and iterate continuously. This is not to say I am not a huge proponent of DevOps and the transformational aspects it can have on the culture of IT, but going fast also has a price.

What do you think? Is DevOps the secret sauce that allows for us to get quality products faster to market? Do you think it has to be one or the other? I'd love your thoughts.

Related posts

Learn more about the latest issues in cybersecurity