Reason #358 why I hate Flash

I use four PCs on a regular basis (two work PCs, plus a laptop and desktop at home), and all three run Windows -- one Windows Server 2003, one Server 2008, and two Windows 7.  All of these boxes are either on 24x7 or hibernated between uses, so the only time I reboot them is to install Windows updates.

And every... single.... time... I reboot any of these machines, I see one of these:

I typically go ahead and let Flash do what it wants to do, and yet it keeps coming back, over and over and over again.  Based on this, I'm forced to conclude that either (1) Flash isn't really updating correctly, or (2) it really does have a new update to install every single time I reboot.

Neither of these is acceptable.  Adobe, you're not building an OS here.  Get it right and get out of my way.  If there's  a *real* new version or a *real* security disaster, then let me know about it, but I just refuse to believe that there are really that many emergencies that you need to install something every single time I reboot.

If you're wondering why folks like Apple have made such a big stink about getting Flash off their systems, this is exactly the sort of issue they had in mind.

The bug “event horizon”

Black holes are fearsome astronomical phenomenon that are so dense and have a gravity well so deep that their infinitely-large mass is compressed into an infinitely small space.  Anything that approaches these monsters is almost certain to be sucked into the hole, and there is a region surrounding each of them where escape is impossible, even for light itself;  it is called the Event Horizon.

The supermassive black holes are all that rema...
Image via Wikipedia

Bugs are like that, too.

A Bug's Life

First-year software development students (and even MBA's) learn that bugs in software are more time-consuming (and thus, expensive) to fix the further along in the software development process they're caught.  The easiest bug to fix is the one you prevent in the first place with proper architecture and design.  Sadly, these quantum bugs are hard to quantify, so good design rarely gets to take credit for these precognitive fixes.

Of the bugs that are actually found, the ones caught during development (perhaps by TDD or unit tests) are wonderfully cheap.  In many cases, mere seconds pass between detection and eradication, the developers' fingers never lifting from the keyboard. These bugs, in fact, are the next best thing to the ones that never existed in the first place, since most of them are never recorded in a bug tracking system and are probably never seen beyond the desk of the developer who found and fixed them.

After code is checked into a version control system, bugs move through a build process and on to testers, while simultaneously being propagated to other developers' desktops via the source code.  Bugs found at this point are slightly more costly to fix, because you've involved other people, and there's very likely a process and tracking system engaged to help keep track of the critters at this point.

But there's another reason these bugs are more costly to fix -- context switches.  As soon as a developer checks in his code, he begins moving on to his next task.  He'll forget all about the code he was working on, including in some cases tearing down whatever virtual infrastructure existed to develop that code.  When he's just about eyeball-deep in his next task, that bug comes home to bite him -- a big context switch.  If the bug is urgent, he's going to have to drop everything and get back up to speed on that code again, leaving behind any progress he managed to make on the new project.

The New Normal

Given that a developer's job is to develop, you'd like him to be able to devote his full attention to creating solid designs and stout code.  In most cases, the work we're asking of these people is really fairly difficult to do well, and it can be nearly impossible if he's not able to concentrate.  When design is interrupted by a bug or two per week, there's very likely an impact in terms of productivity as the developer changes contexts, but concentration and software design shouldn't be adversely affected to a large degree.

As interruptions become more frequent and prolonged, however, there can be an impact in the quality of new code that's produced, as well.  Design becomes disjointed and inconsistent.  Code becomes sloppy.  More new bugs are introduced.  We've introduced a vicious cycle of downwardly-spiraling quality.

As bug counts grow, they can start to have an impact beyond development and QA areas.  Help desks can become buried in calls; bugs begin to go un-recorded and uncorrected.  The noise level caused by poor software quality can contribute further to the downward spiral of quality.


When code quality suffers so completely that the organization cannot produce high-quality code, the transformation of the organization is complete.  Buggy code eventually results in even buggier code, and software collapses upon itself as if it was a black hole.

Is the Demise Inevitable?

Unlike a real black hole, the problem of software quality can be stemmed -- especially if it's caught early.  Much like bugs themselves, though, the later this issue is addressed, the more difficult and expensive it will be to fix the problem.  When you consider the cost of bugs in your organization, don't forget the cumulative effects of bugs on the quality of the work you're able to produce.


Enhanced by Zemanta