Mozzilla Thinks Crashes are a GOOD Thing...Really?

by

My six-year-old can tie her own shoes. I honestly did not realize how big of a deal that was until her teacher told me a few months ago that she had, for a short time, become the designated shoe tier in her classroom. Apparently, thanks to the advent of Velcro closures for kids’ shoes, nobody else in her kindergarten class knew how to tie their shoes.

The problem with being a “star” of your kindergarten class, however, is that all the kids want their shoes tied by her. As a result, she was trying to tie shoes very fast – too fast, in fact – and started making mistakes, which got her frustrated when the knots don’t come out right.

Seeing this frustration, I calmly remind her that it is better to do something right than to do it fast. This is a lesson many software development teams also need to remember.

Huh?

While you would think “getting it right” should be the first mantra of developers, though, we see more and more examples of teams finding ways to do things “faster” rather than focusing on quality. While it is true that in order to keep up with competition and demand the current market dictates shorter development cycles than decades past, that does not mean quality needs to be sacrificed or done “on the fly.”

Nevertheless, eschewing quality for speed seems like that’s exactly what’s going on over at Mozilla. Over on the appropriately named blog “It Will Never Work in Theory,” a section from a paper titled “Do Faster Releases Improve Software Quality? An Empirical Case Study of Mozilla Firefox” by Foutse Khomh, Tejinder Dhaliwal, Ying Zou, and Bram Adams is studied. The paper finds:

  1. Users experience crashes earlier during the execution of versions developed following a rapid release model.
  2. The Firefox rapid release model fixes bugs faster than using the traditional model, but fixes proportionally less bugs.
  3. With a rapid release model, users adopt new versions faster compared to the traditional release model.

The post goes on to evaluate these findings, noting that the third point is good news, item two is kinda good news, but item one is a head scratcher.

Really?

I doubt anybody would find fault with the third finding from the Mozilla case study. Adopting new versions faster than traditional models is certainly a positive in business. However, there’s something missing here; are developers building these versions faster AND stable or are they just developing them faster without concern for application software quality? If those versions are just being done faster and are not being built well, they will require development teams to go back and constantly fix issues and could possibly lead to major malfunctions that interrupt business continuity. I don’t see how that is a good thing.

What is really confounding, though, is the first finding in the Mozilla case study, “Users experience crashes earlier during the execution of versions developed following a rapid release model.”

How exactly is that positive in any way, shape or form?

The last I checked, the earlier an application crashed the more poorly written, less reliable, more destructive and more useless it was. I don’t think there’s a single Marketing department in the world who could successfully promote its application software by saying, “We Crash Faster!”

I would have to guess the authors of the case study believe that if users experience crashes earlier in the execution of versions it means developers at Mozilla can start fixing those bugs sooner. That’s not a great way to run a business, though. Where’s the concern for software quality? Moreover, when did Mozilla start paying its users to serve as its software quality inspectors?

Maybe that’s why Mozilla Firefox is offered as a free application to its users…because users should know they get what they pay for!

Eventually my child's teacher stopped sending students to her to have their shoes tied because the teacher was just having to retie them. I suspect as Mozilla users experience these earlier crashes, they, too, will look elsewhere to "have their shoes tied."

Get the Pulse Newsletter  Sign up for the latest Software Intelligence news Subscribe Now <>
Open source is part of almost every software capability we use today. At the  very least libraries, frameworks or databases that get used in mission critical  IT systems. In some cases entire systems being build on top of open source  foundations. Since we have been benchmarking IT software for years, we thought  we would set our sights on some of the most commonly used open source software  (OSS) projects. Software Intelligence Report <> Papers
In our 29-criteria evaluation of the static application security testing (SAST)  market, we identified the 10 most significant vendors — CAST, CA Veracode,  Checkmarx, IBM, Micro Focus, Parasoft, Rogue Wave Software, SiteLock,  SonarSource, and Synopsys — and researched, analyzed, and scored them. This  report shows how each measures up and helps security professionals make the  right choice. Forrester Wave: Static Application Security Testing, Q4 2017  Analyst Paper
This study by CAST reveals potential reasons for poor software quality that  puts businesses at risk, including clashes with management and little  understanding of system architecture. What Motivates Today’s Top Performing  Developers Survey
Jonathan Bloom Writer, Blogger & PR Consultant
Jonathan is an experienced writer with over 20 years writing about the Technology industry. Jon has written more than 750 journal and magazine articles, blogs and other materials that have been published throughout the U.S. and Canada. He has expertise in a wide range of subjects within the IT industry including software development, enterprise software, mobile, database, security, BI, SaaS/Cloud, Health Care IT and Sustainable Technology. In his free time, Jon enjoys attending sporting events, cooking, studying American history and listening to Bruce Springsteen music.
Load more reviews
Thank you for the review! Your review must be approved first
Rating
New code

You've already submitted a review for this item

|