Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start 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.

No, thanks

Myth Buster

Talk from JAX 2015. We know quite a few things about software development - for more than 40 years. E.g. the waterfall model doesn't really work - and its origins are unclear. Or: It's dangerous to add people to a project - also for the architecture.

Eberhard Wolff

on 15 January 2017

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Myth Buster

Myth Buster
...or: Do We Even Learn?

Eberhard Wolff

Anyone read the original paper?
45 years ago
Iterations recommended
Problems of waterfall
were understood
Software History Maturity Model
Level -1 to 5
This is
Level 3
Software engineering
is so young!
What can we know?
We don't learn.
Aerospace / Defense
Winston Royce
Paper does not use the name "Waterfall"
When was the paper cited the most?
Source: The Leprechauns of Software Engineering
Barry Boehm
Royce did not coin "Waterfall"
IBM System/360
First computer family
Shipped 1965
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
Pre agil
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
Mythical man-month:
Microservices limit communication
Less centralized architecture
Independent modules
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!
Conway's Law
communication structures
of the organization
Similar to Royce
Higher communication overhead eliminates benefits
I should be payed by # of emails
All I do are meetings
Large System
(Too) many people
Communication hard to impossible
Communication breaks down
Architecture breaks down
Communication = architecture
Size of team influences organization
...and therefore architecture
Parkinson's Law
Work expands
so as to fill
the time
available for its completion
Manager's prestige and power depend on size of his organization
Large and complex architectures / organizations evolve
Software interface
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
be careful!
The foundations of the Waterfall model are weak
...and shortcomings are very well known
We need empirical studies!
Why is anyone seriously considering it?
= Communication
= Organization
Far reaching implication
No running System/360 exists today
Successful migration!
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
Full transcript