the agile heresy: what drives traditional software engineering, and why agile turns it

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

Upload: wenda

Post on 22-Feb-2016

28 views

Category:

Documents


0 download

DESCRIPTION

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 - PowerPoint PPT Presentation

TRANSCRIPT

Page 1: 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

Paul Ammann

http://cs.gmu.edu/~pammann/Upside Down

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

04/22/2023 2

The Caricature

It’s Fun To Spin, But Let’s Look A Little Deeper

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

04/22/2023 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.

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

04/22/2023 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 errorsIn 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

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

04/22/2023 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”

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

04/22/2023 6

Traditional Cost of Change Curve

Standard Motivation For Up Front Design Techniques

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

04/22/2023 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

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

04/22/2023 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

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

04/22/2023 9

Defect Discovery: Agile vs. Traditional

It’s All About The Deltas

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

04/22/2023 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’t Gonna Need It

The Heresy: Counter To Decades of Design Philosophy

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

04/22/2023 11

Agile Cost of Change Curve

A Good Agile Project Builds Something Different and Better Than The Original Design

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

04/22/2023 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