1 / 12

The Agile Heresy: What Drives Traditional Software Engineering, and Why Agile Turns it

The Agile Heresy: What Drives Traditional Software Engineering, and Why Agile Turns it . Upside Down. Paul Ammann http://cs.gmu.edu/~pammann/. The Caricature. It’s Fun To Spin, But Let’s Look A Little Deeper. Overview. Traditional Evolutionary Design circa 1970 A Disaster! Planned Design

wenda
Download Presentation

The Agile Heresy: What Drives Traditional Software Engineering, and Why Agile Turns it

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The Agile Heresy:What Drives Traditional Software Engineering, and Why Agile Turns it Upside Down Paul Ammann http://cs.gmu.edu/~pammann/

  2. The Caricature It’s Fun To Spin, But Let’s Look A Little Deeper

  3. Overview • Traditional Evolutionary Design circa 1970 • A Disaster! • Planned Design • Managing The Cost Curve Through Upfront Analysis • The Heart of Modern Software Engineering • Agile Approaches • The Return Of Evolution • Managing The Cost Curve Through • Testing • Post Development Design • This Presentation Draws Heavily on Fowler and Ambler • Is Design Dead?, The New Methodology • Examining the Agile Cost of Change Curve Déjà vu all over again.

  4. Traditional Evolutionary Design • Successful In Other Engineering Disciplines • Each Successive Widget Is an Improvement • In the Beginning, Programmers Just Programmed • Result Was Ad Hoc Structure • Eventually Hard – Impossible, Actually - To Maintain • The tendency towards irreducible number of errors In a suitably complex system, any attempt to fix observed errors tends to result in the introduction of other errors - Brooks • Key is managing complexity Why Software Engineering Developed as a Field

  5. Planned Design • Introduction of Traditional Development Phases • Requirements, System Design, Detailed Design, etc. • Heavy Reliance on Upfront Analysis The big errors are made at the beginning and rarely recognized. If caught at all, it is usually after fielding. The lesser errors surface as soon as coding begins and shout out when the first real user tests a prototype - Brooks • Early Life Cycle Effort Has Huge Potential ROI • Anticipate Change, and Plan for it • Identify Defects Early Success Defined As “On Time and On Budget”

  6. Traditional Cost of Change Curve Standard Motivation For Up Front Design Techniques

  7. Is Software Engineering Really Like Other Engineering • Separation of Design and Construction • Design is hard to predict; Construction is easy to predict • But software engineering is all design! • The Unpredictability of Requirements • No stable requirements means no predictable plan • But everyone recognizes that software requirements are soft! • Controlling Unpredictable Processes with Iteration • Working versions introduce reality – always a good thing. • The Adaptive Customer • Business value is hard to articulate precisely in advance Perhaps Software Engineering is Different

  8. Agile: The Return of Evolution • The Problem With Traditional Design: • The Track Record of Anticipating Change is Pretty Lousy • Extremely Difficult To Maintain Non Executable Documents • How Relevant Is Your UML After Six Months? • What Does It Mean If Your Design Needs To Change? • Failure In Prior Design Process? (Traditional) • vs • Normal First Class Problem In Software Engineering? (Agile) • How Often Are You Running Your Tests? • Key Gap: Making Mistakes vs. Finding Mistakes • Key Gap: Divergence Between Different Development Teams Software Evolves Whether We Like It or Not

  9. Defect Discovery: Agile vs. Traditional It’s All About The Deltas

  10. A Different Approach To Managing The Cost Curve • The Test Harness As Guardian • (Near) Instant Feedback on Changes (or Mistakes) • An Hour? Ten Minutes? Less? • Implies Something Is Executable From The Very Beginning • The Role of Continuous Integration • Effective Communication Mechanism • De-Emphasize Non Executable Artifacts • If It Doesn’t Execute, It’s Not Checkable • Hence, It Rots… • Avoid Anticipating Future Needs • YAGNI: You Ain’tGonna Need It The Heresy: Counter To Decades of Design Philosophy

  11. Agile Cost of Change Curve A Good Agile Project Builds Something Different and Better Than The Original Design

  12. Refactoring – The New Design • Design Still Matters • Agile Distributes Design Effort • Focus is on Needed, Rather Than Anticipated, Functionality • Refactoring Requires Recognizing Defective Designs • And Replacing Them with Functionally Equivalent Designs • Requires Basic Training in Code Smells • Maintenance vs. Green Fields Development • After First 15 Minutes • All Projects Are Maintenance Projects Design as a Post Development Activity

More Related