Anew force is making itself felt in the world of software development. Advocates of the agile development methodology (www.agilealliance.com) claim that its potential to increase productivity in some areas is so bright that coders are going to need to wear shades to write software with it.
Instead of starting by developing a detailed set of requirements, agile methodologies call for programmers to begin by writing small chunks of functionality that can be completed in two to four weeks -- "iterations," in agilespeak. Module testing receives the same level of attention as the actual writing of the code. When one iteration is done, developers find the next requirement to add more functionality to the module just completed and thereby start a new iteration.
Agile processes promise to deliver high-quality, functioning software at a fraction of the time and cost of traditional methods. Still, agile isn't likely to replace the so-called waterfall development methodologies, those proven ivory towers that have been used for the development of everything from missile guidance to widget-tracking ERP systems. For many projects, especially big ones with relatively fixed requirements, the Software Engineering Institute and its family of Capability Maturity Models (www.sei.cmu.edu/cmmi) are the gold standard and will remain so.
What's changed is product development in the era of global mass customization. You can't afford a three-month requirements-definition phase whose pieces are nebulous and evolving. The agile method has at its core the ascendance of trial and error over planning and documentation or, borrowing more agilespeak, "early value delivery" over "formalism."
Agile tilts to a more intuitive but still disciplined form of software development. Build and test a software module for that widget-tracking system with a very small, tightly integrated team. Then interpret the requirements for that module in the testing and have the software built before the requirements even would have been developed using traditional waterfall methods.
Agile already is showing up in mainstream software development. Some developers will see it first as part of a hybrid methodology, with some parts managed via waterfall methods and others spun off to agile. Likely candidates for spinning off to an agile team are software modules that include undefined areas or functionality that's likely to change.
Instead of waiting for dependencies to be resolved or customer inputs to catch up to requirements, put agile to work. Develop the test plan, build, and test with "Tinkertoy" interfaces that can be easily updated when the project catches up. Agile excels in this environment.
The potential savings offered by the agile method force the global software development marketplace to take it seriously. Its pros and cons are hotly debated. If agile does what its proponents claim, it will be disruptive technology for software development, changing everything.
And if everything changes, there will be winners and losers. The winners will include a lot of those early proponents who were able to see and embrace the change -- and who didn't have a large stake in the entrenched way of doing things. The losers will mostly be development shops that have a large stake in the ancient regime and are unable or unwilling to embrace the change.
Squarely in the sights of some agile proponents is the movement to offshore development. Examined through an agile lens, those billions of dollars spent in developing software offshore are suspect. Is it better to write a great set of requirements and enforce an elegant project management system to gain the economic benefit of cheap offshore development? Or should we begin defining an agile iteration in parallel with a test plan and begin writing software close to home for early delivery of a functioning solution?
Offshore development puts considerable stress on some of the cultural practices fundamental to agile, such as small teams working in close proximity, instant communication and tightly integrated testing. Disruptive technology changes the rules in Bangalore, Boston, Beijing and Berlin. Being close to the agile project -- "visibility," in agilespeak -- puts a premium on proximity and new types of project management tools.
But it would be a mistake to assume that agile brings a sustainable advantage to onshore developers in the U.S. Once the offshore community gets on board with agile -- and they are starting to do so - they will adopt new management tools and methods and continue to enjoy the same cost advantages they do now, albeit at a faster pace.
Mark Willoughby, CISSP, is a 20-year IT industry veteran and journalist. He can be reached at email@example.com.