Agile vs Haphazard development

Before IT can be brilliant and transformational it has to get the basic blocking and tackling right … testing, for example.

ManagementSpeak: There’s not a deadline on this, but efficiency is key.

Translation: Call your significant other and warn them that you’ll be getting home late … for the next few months.

Gerry Giese joins the KJR Club with great efficiency.

Ever wonder why good code is so hard to find? In his consistently brilliant xkcd.com, Randall Munroe explains the situation: Write fast and write junk. Write well and your software is obsolete before you’re done.

It’s Waterfall vs Agile, of course. And the debate, unsurprisingly, is more often tribal than rational — my team is better, which I can prove by pointing out the other team’s flaws.

And so, Waterfallers focus on the similarity between Agile’s touching faith in refactoring and UFOlogists’ certainty that civilizations capable of interstellar travel have no better way to communicate with us than to create a big circle in a corn field.

Meanwhile, Agilites concentrate on the number of web pages we’d have in production right now had the Web been produced through waterfall techniques (an estimated 6,427 total pages in total; IBM would be just about ready to put up its OS/2 support area).

Fun as it is, finding the sins of others does nothing to expiate our own, which brings us (more or less) to this week’s sermon — a response to subscriber Donna Bushard’s request that KJR talk a bit about Agile testing.

Here’s my first bit: I’m in favor of it.

In case you want more on the subject … in the old world of waterfall methodologies we recognized these levels of testing (or, better-because-it-sounds-a-lot-more-impressive, software quality assurance (SQA)):

• Software engineering (does my code adhere to the overall system architecture, is it properly structured, and does it adhere to coding style standards?)

• Unit (does my module do what it’s supposed to?)

• Integration (does my module interact properly with all the other modules the team is creating?)

• Regression (do our new modules break anything that’s already in production?)

• Stress (will the whole system perform well enough once everyone starts to bang on it?)

• User acceptance (are the new modules aesthetically pleasing? And, although it’s probably less important, do they do what the business needs them to do?)

The question: How does Agile change this? The answer: Agile doesn’t. There are, however, IT shops that think “Agile” means “Free-for-all,” and free-for-all development does change everyone’s thought process about SQA … namely, it eliminates the whole subject.

Agile is, as everyone ought to know by now, both a family of methodologies with two shared critical elements — iteration, and high levels of informal end-user involvement — and a religion, complete with sects, offshoots, and wars between adherents of the competing theologies.

The religious wars notwithstanding, one of Agile’s best features is that its high levels of informal end-user involvement make user acceptance testing something close to a non-event. When it happens, there will be nothing in the application end-users are seeing for the first time.

Iteration is where Agile gets into the most trouble from a software engineering perspective. The temptation to take structural shortcuts just this once can be overwhelming. That’s why code reviews are, if anything, more important with Agile than with waterfall projects. Except for eXtreme, of course, where code review happens while code is being written.

And in case the point isn’t clear, Agile projects require an overall architecture plan, just as waterfall projects do. Like most things Agile, the architecture plan should itself be iterative, with the high-level view developed up front and the rest happening as developers recognize when they are making design decisions that have architectural impact. For the other SQA steps:

Agile unit testing is little different from waterfall. Either way, developers can’t be relied on to unit test their own modules, because when developers have blind spots that result in defects, they bring those same blind spots into their unit tests.

What is a bit different is that as developers iterate they must keep track of how each iteration adds new test cases. Figuring them out later is a whole lot harder than jotting them down as they’re happening.

How you handle integration, regression, and stress testing depend on whether IT has invested the time, effort and infrastructure to develop an automated test suite. If so, take advantage of it and run it frequently … perhaps even nightly.

If not, make integration, regression, and stress testing waterfall tasks that take place at the end of each release cycle. And whatever you do, make them incompressible.

You might as well, because when it comes to testing there’s exactly one certainty: You always test, and you always test thoroughly. You don’t have a choice.

The choice you do have is whether you test before you put the software into production or after.

Before is better for your image.

Bob Lewis is author of Keep the Joint Running: A Manifesto for 21st Century Information Technology, Bare Bones Change Management: What you shouldn’t not do, and six other books on business, information technology, and where they intersect. He is president of IT Catalysts, Inc., a consultancy specializing in these and related areas.