15 May Are you doomed to repeat the great software mistake?
The history of software development teaches an interesting lesson.
In 1970, Dr. Winston Royce authored an article titled “Managing the Development of Large Software Systems.” Appearing in Proceedings, IEEE Wescon, the article gave birth to the waterfall development methodology that would plague the software industry for decades to come.
Unfortunately, many software development teams continue to make the great mistake.
Birth of waterfall
The waterfall method of software development is a sequential software development model where development flows steadily downward through multiple phases. The approach demands stabilization of requirements, followed by thorough analysis and design, implementation, testing, and deployment.
Unfortunately, waterfall methodologies operate under the fatal assumption that requirements can be stabilized. Today, we recognize that an inherent characteristic common to all software development efforts is virtually constant change. The waterfall methodology, born of Royce’s article, is a direct contradiction to the intrinsic nature of software development.
Closer analysis of Royce’s article confirms a significant misunderstanding. To simplify his explanation, Royce presented the phases of the software lifecycle in a linear fashion. However, he quickly moved on and commented that such an approach “…is risky and invites failure.” Explaining in more detail, he described the need for an iterative model, where a development team progresses through the process, passing over unnecessary steps.
In fact, Royce’s article does not include a single reference to the term waterfall, leaving subsequent interpretations of the article to invent the flawed method. It would take more than two decades for the essence of Royce’s message to gain traction.
Iterative development methods promised to fix the problems inherent to the waterfall model by producing software in smaller, more manageable chunks. The early days of iterative development proved rather tumultuous, however, as teams struggled to grasp the deep significance of iterative and incremental software development.
Spearheaded primarily by vendors and large IT consultancies espousing the virtues of their elaborate methods and tools, the ideals endorsed by iterative development were quickly lost in a deep tangle of complexity. Computer-aided software engineering tools quickly became the tools du jour, often accompanied by ceremonial methods that, if followed rigidly, promised to lead development teams through the quagmire.
While sound conceptually, the tools and methods came with steep learning curves and inflexible processes and procedures. For many teams, iterative development resulted in labeling traditional waterfall phases as iterations, while adopting new technology and tools. Even now, many organizations continue to struggle with iterative methodologies such as the Rational Unified Process (RUP).
Agile development expands, yet simplifies, the ideals sought by iterative methods. Recognizing that software development is not a predictable endeavor, the following characteristics set agile development efforts apart.
• Frequent delivery to gain frequent feedback – Agile teams treat functional software as their top priority. Testing early and often, they continuously verify software quality, and through frequent customer prototypes and demonstrations, ensure the team is on the right track. By tightening the feedback loop between IT and business, they ensure the team stays on the right track. Traditional methods failed to adequately evangelize this very important attribute of successful software projects.
• Empower people, not process – Skeptics might argue that agility is nothing more than cowboy coding, where the development team does whatever it wishes. While lacking the ceremony and rigidity of traditional methods, agile methods do not lack formality. Instead, their differentiating factor is recognition of software development as a human activity, allowing process to conform to people over people conformance to process.
• Stay lean by eliminating waste – A common misunderstanding is that agile methods shun all documentation. In fact, documentation is an important artifact required of all IT projects. Yet excessive documentation offers a false sense of security, leading project stakeholders to believe the documentation is an accurate reflection of software system functionality. Agile teams recognize that the only software artifact providing an accurate assessment on the current state of the development effort is the software itself.
• Favor intense collaboration – Traditional processes emphasize contractual relationships with business stakeholders. Yet far greater success can be realized by working collaboratively, as a united team toward a common goal.
• Recognize change as inherent – Planning is an important aspect of all IT projects. However, enforcing a plan over adapting to change can quickly misguide a team. Agile teams treat change as an opportunity.
Adopting an agile practice or methodology cannot guarantee software development success. In fact, agility is defined by ability, not process. By aggregating proven agile practices, even when faced with constant change, teams are able to reliably and frequently deliver functional software. Increased agility, and its emphasis on frequent software delivery, will strengthen the relationship between IT and business.
Previous article by Kirk Knoernschild
• Kirk Knoernschild: Agile Revolution: A new era of software delivery
• Robert Merrill: Defining the X-factor: What is an ounce of software worth?
• Study affirms information technology-productivity link
He is the author of Java Design: Objects, UML, and Process, and a frequent contributor to The Agile Journal, where he writes The Agile Developer column. His personal website is www.kirkk.com, and his planet is http://planet.kirkk.com.
The opinions expressed herein or statements made in the above column are solely those of the author, and do not necessarily reflect the views of Wisconsin Technology Network, LLC.
WTN accepts no legal liability or responsibility for any claims made or opinions expressed herein.