Hey Agile: Good Enough Ain’t Good Enough

Posted By Jonathan Bloom on January 17, 2012 | Application Quality

As a writer, I frequently go back and review pieces I’ve written over time. When I do, I’d like to think that I’ll be happy and satisfied with each and every article, announcement, blog or brochure.

The truth is, however, that I seldom find that I’m patting myself on the back for a job well done…and I’m not talking about just typos. More often than not, somewhere within the piece I’ve written there is a paragraph, sentence, phrase or word that makes me wince and wish I’d taken a different approach or just worded things differently.

So I’m not perfect; that’s no newsflash (just ask the folks I work with…but don’t ask my wife unless you want an entire litany of my foibles). However, as a writer and blogger I can afford to produce something that’s “good enough” for publication. This was especially true when I was covering breaking news and writing under deadlines for a daily newspaper. What gets me is that there are those in the Tech industry who actually believe that good enough is good enough when it comes to application software.

Are you kidding me?

Technology Shouldn’t Imitate Art

We frequently hear those in industry lament that today’s workers take no pride in their jobs. They ignore the call for quality in an effort to meet quotas that bring them bonuses. It seems some in the Tech industry similarly see speed and quantity as the more important factors in developing software.

Recently, Andy Beal, CEO of social media monitoring tools vendor Trackur, posted an item on the American Express Open Forum in which he offers, “5 Reasons Why Being Agile Is More Important Than Being Perfect.” He introduces his argument by citing filmmaker John Lasseter, who says, “We don’t actually finish our films, we release them.”

In other words, Lasseter recognizes that with art you can go on forever making edits, reshooting and tweaking things; it will never reach a level of perfection in your mind or anyone else’s for that matter. In art – be it film, music or writing – good enough can be good enough. Heck, even after putting off his 1975 release of “Born to Run” to get every song on that album “perfect,” Bruce Springsteen to this day tweaks the tunes he plays from that album to make them “better” for that specific time and place.

But when it comes to application software – and mission critical software in particular – how can good enough be good enough? “Good enough” is what results in malfunctions. “Good enough” is what causes outages. “Good enough” is what leaves undetected the vulnerabilities from old versions of software that wind up being gateways for hackers who exploit them to steal sensitive data files.

And They’re Off…

Right from the start, Beal’s argument of why being agile is more important than perfection falls flat. His first point – speed wins – is hollow and even he attempts to back off from it. He posits that the first to market gains market share and customers, but he qualifies this by saying “you don’t want to be sloppy.” Well, therein lies the problem. Invariably, pushing application software to achieve arbitrary deadlines results in shortcuts being taken and, in too many cases, sloppy software. Sorry, but speed doesn’t win; speed kills.

Beal also tries to make the point that being agile – which he seems to equate with being fast (I equate it with being adept and adroit) – energizes employees and customers. What he seems to fail to take into account, however, is how that energy fades quickly and turns to disdain if the product that is rushed out the door winds up failing in some way. How “energized” are the IT teams at Sony, Sega, Citigroup, the London Stock Exchange, the Department of Defense or any of the other organizations that suffered some form of IT failure last year? How energized are their customers? I know Sony is “energized” to the point of 55 class action lawsuits and nearly $200 million in reparations.

Striving for Perfection

While I do believe speed kills, I also am not so jaded as to believe that true perfection can be reached. As Salvador Dali said, “Have no fear of perfection – you’ll never reach it.” But that doesn’t mean you don’t at least try to achieve it.

Beal also points out that ultimate perfection is not achievable. He notes that those companies that continue to tinker with application software run the risk of being beaten to market by a competitor that could, perhaps, launch a similar product that costs less and works better. But should software that is knowingly not up to snuff in terms of structural quality be released just to be first? I don’t think so. In fact, I believe author Francis J. Kong said it best, “The early bird catches the worm but the second mouse gets the cheese.”

Just because software can’t be perfect, that does not mean speed should undermine the effort to make it as close to perfect as possible.

There’s no reason why agile needs to settle for “good enough.” By taking the time to employ something like automated analysis and measurement to provide visibility into the application software and identify structural quality issues during the build process, agile developers will be more likely to correct issues while they are still relatively simple to fix and optimize the structural quality of the software. Optimal quality software makes for happy customers, not to mention more uptime, fewer headaches and lower technical debt because post-deployment problems should be few and far between.

That’s all for now…I hope it was “good enough.”

Tags: Agile, Android, Application Quality, automated analysis and measurement, SCRUM, software analysis, Software Development, software measurement, structural quality, Technical debt