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.
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:
Users experience crashes earlier during the execution of versions developed following a rapid release model.
The Firefox rapid release model fixes bugs faster than using the traditional model, but fixes proportionally less bugs.
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.
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.”