Send the link below via email or IMCopy
Present to your audienceStart remote presentation
- Invited audience members will follow you as you navigate and present
- People invited to a presentation do not need a Prezi account
- This link expires 10 minutes after you close the presentation
- A maximum of 30 users can follow your presentation
- Learn more about this feature in our knowledge base article
Do you really want to delete this prezi?
Neither you, nor the coeditors you shared it with will be able to recover it again.
Make your likes visible on Facebook?
Connect your Facebook account to Prezi and let your likes appear on your timeline.
You can change this under Settings & Account at any time.
Transcript of Myth Buster
...or: Do We Even Learn?
Anyone read the original paper?
45 years ago
Problems of waterfall
Software History Maturity Model
Level -1 to 5
is so young!
What can we know?
We don't learn.
Aerospace / Defense
Paper does not use the name "Waterfall"
When was the paper cited the most?
Source: The Leprechauns of Software Engineering
Royce did not coin "Waterfall"
First computer family
Cost: $5 billion
Second only to Apollo moon program
Foundation for IBM's mainframe business
No instant hit
Why are we still considering Waterfall?
What are the foundations of the Waterfall model?
by Frederick Brooks
Project manager System /360
Plan to throw one away
Requirements done once
This is not agile
You will anyhow.
Even if it was in production.
The only constant is change
Plan the system for change.
Plan the organization for change.
New features introduce new bugs:
2 steps forward,
1 step back
# Modules increase linearily
1 step forward,
1 step back
Affected modules increase exponentially
But no true iterations
What can we learn from this huge and important project?
Issues for agile & agile architecture
The project is late.
We need more resources!
Adding resources to a late project makes the project even later.
n developers have n(n-1)/2 communication channels
New developers must be trained and understand the project
Microservices limit communication
Less centralized architecture
Independent streams of stories
Microservices scale development?
Buy three copies
Read it three times as fast!
The Bible of Software Engineering:
everybody quotes it,
some people read it,
and a few people go by it
But adding resources is even worse!
of the organization
Similar to Royce
Higher communication overhead eliminates benefits
I should be payed by # of emails
All I do are meetings
(Too) many people
Communication hard to impossible
Communication breaks down
Architecture breaks down
Communication = architecture
Size of team influences organization
...and therefore architecture
so as to fill
available for its completion
Manager's prestige and power depend on size of his organization
Large and complex architectures / organizations evolve
requires people talking to each other
Didn't tell you everything
Royce's focus on documentation
Do it twice
Brooke's Surgical Teams
Judge for yourself
Next time you want to add resources
The foundations of the Waterfall model are weak
...and shortcomings are very well known
We need empirical studies!
Why is anyone seriously considering it?
Far reaching implication
No running System/360 exists today
First project of this size
Expressing effort in man-month is useless -
won't scale with # developers
Brooke's "No Silver Bullet"
i.e. no single technology gives order of magnitude better productivity