Revisiting Software Development
Prepared by M Junaidi
Grievances in Software Development
- Failure to meet deadlines.
- Failure to take account of customer feedback.
- Excessively slow programs.
- Dispersion of programming staff.
- Lack of technical writing effort for documentation.
- Lack of software knowledge outside of the programming group.
- Interference from higher managers who imposed decisions, "...without a full realization of
the more intricate implications of the matter."
- Overoptimism in the face of pressure from customers.
In which year do you think it was written?
It was 1965.
Does it sound familiar?
Why does it keep repeating in modern software development projects?
Don't we should have the solution already?
Objectives
To identify the problems in our software development approaches. (The challenge)
To learn from the people of the past how they solve those problems. (The solution)
Case Study I: Elliott 503 Mark II Operating System
- Led by Tony Hoare.
- From Oct 1963 to March June September 1965 (18 + 3 + 3 = 24 months)
- Started with 15 programmers
- Unsuccessful and abandoned along with "over
thirty man-years of programming effort."
- Failure to meet deadlines.
Case Study II: IBM System/360 Operating System (OS/360)
- Managed by Fred Brooks.
- Announced in 1964.
- Developed by IBM for their then-new System/360 mainframe computer.
- Discontinued.
- Possible reasons:
- Required more memory than planned.
- The development would take much longer than expected.
Case Study III: Multics
- A time-sharing operating system.
- Led by Fernando Corbató a.k.a Corby (MIT).
- 1964: Started by MIT, GE, Bell Labs
- 1969: It failed to produce the timesharing system as planned. Bell Labs pulled
out.
- 1970: Honeywell taken over.
- 1987: Commercially unsuccessful, development stopped.
- 2000: Last Multics machine was shut down.
- Considered too complex more than expected.
Why these 3 cases?
The projects led and implemented by intelligent people, yet they failed.
"If only we could learn the right lessons from the successes of the past, we
would not need to learn from our failures."
- Tony Hoare
Why these 3 cases?
They inspired many of software development approaches exist today.
How?
Tony Hoare produced Emperor's Old Clothes.
Fred Brooks produced Mythical Man-Month and No Silver Bullet.
Corby produced on Building Systems That Will Fail.
Similarities?
Failure to meet deadlines.
Too complex more than expected.
Or we can say...
... failure to produce the expected result within the expected period of time.
Or can be summarized as...
... inaccurate estimation.
So how do we make better estimation?
Making better estimation
Understand that software development is complex.
Brooks defined there are two types of complexity:
- Accidental complexity - Problems which engineers create and can fix. (Non-functional requirement)
- Essential complexity - The problem to be solved, and nothing can remove it. (Functional
requirement)
Making better estimation
Separating between two types of complexity.
Reduce these accidental complexities to 0 (unlikely, but we have to try).
How?
- High-level languages. (DONE)
- Time-sharing systems. (DONE)
- Unified programming environments. (DONE)
What else we can do to reduce accidental complexities?
Making better estimation
Reducing Accidental Complexities
- High-level languages (DONE)
- Brook's Law
- Software - grow, not build!
- Good designer vs. great designer
References
- 1981, C. A. R. Hoare, The Emperor's Old Clothes, PDF
- 1975, Fred Brooks, The Mythical Man-Month, PDF
- 1986, Fred Brooks, No Silver Bullet — Essence and Accidents of Software Engineering, PDF