The first in a series discussing truisms, problems, tips, and techniques for the difficult
problem of developing large software projects. Here, we focus on problems and pitfalls.

Optimism
• I am warning you about the various danger areas that can wreck a software project so
you can be aware of them. However, Java is a great language, OOP design works
very well, and teams are well able to use their judgment to course-correct as they go.
Many CS108 projects do their planning diligently, code in parallel, and then find, to
their relief, that it all fits together and runs nicely -- escaping the many catastrophes
described here. :-)

The Bad News
• Uncertain
• Expensive
• Intangible -- hard to judge the current state
• Huge time-to-market issues
• Fad processes, gurus -- the "silver bullet" wish

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

Tradeoff Problems
The Three Variables -- "Tradeoff"
• Features - Time - Quality
- As time runs out, either features or quality will have to give.
• Classic Error: Denial
- Denial. The project proceeds with an optimistic sense of its progress. As time runs
out, nobody admits how low the quality is for the chosen feature set. The deadline
arrives, and you end up shipping a project with features that are 80% done.
• Eyes Open
- Would have been better to accept the reality halfway through the project, cut some
features, and end up shipping with a smaller number features 100% done.

• Alternate phrasing
- It can be done on time. It can have all the features you want. It can be done well.
Trade among these.
• Quotes
- "Fast, Cheap, Good -- pick any two"
- poster of above: noise to signal: Pick any two
- "You want it bad? We'll give it to you bad!"
• Challenger Explosion Example
- Features vs. deadline vs. safety tradeoff. Safety was intangible vs. the others, so it
kept losing the little tradeoff decisions. Software quality can be hard to measure in
the same way..
• Conclusion
- Take testing and milestones seriously to evaluate the current state or the project.
Avoid denial. Make informed decisions early that balance the three variables.
• Note: People
- You could argue that "people" is a fourth variable -- you could increase the number
of people to do better with the other three variables.
- I don't present it that way, since it is generally accepted that adding people to an inprogress
project is often counterproductive. Fred Brooks quote: "adding people to
a late software project makes it later." We'll talk about this later -- it is roughly
true that adding people works poorly, but not some kind of law.
Time Problems
Underestimating Time to Finish
• Everything takes longer than you think
• i.e. the "Iceberg" principle
• Old joke: take the estimate, double it, go up to the next unit of measure. So "2 weeks"
means "4 months"
• External/Abstraction View
- The way you think about something from the outside -- how it interfaces with other
things.
- The abstraction it presents.
• Internal/Implementation View
- The external view + all the details and quirks of how it is actually implemented.
- The internal view is much more complex than the external view.
• Iceberg Analogy
- 20% of the iceberg sticks above the surface, but most of the iceberg is below the
waterline.

- With most systems, we observe the obvious part sticking above the water line and
use that view in our mental models. Most of the complexity is not visible.
Tend To Plan in terms of External View
- When thinking about a system, we tend to use the external view for the various
components. (I believe this is an inherent feature of using a brain which must use
conceptual simplifications to think about a complex world.)
Underestimate
- As a result, estimates invariably understate the total complexity. This happens every
time.
Allow Extra Time
- There will always be unexpected details and problems -- allow extra time for them.
This applies to any project (a paper, a widget, a movie, a vacation). There's
always more work in the details than is apparent from the external view of the
finished product.
- When making schedules, allow an extra 50% to deal with the inevitable
"unexpected" problems. "Under promise, over deliver"
e.g. Making List of Tasks
- Suppose you were to try to list out ahead of time all the tasks in a software project.
- 1. Make a list ahead of time of all the methods and issues which a piece of software
will need to deal with
- 2. Do you really think you've thought of everything in (1)? All the unexpected
bugs? All the blind alleys? It's guaranteed that there will be issues which are only
revealed during the implementation. Could add a blanket "things we haven't
thought of in this list" item to the list.
When Can you have X done?
When planning a project, the answer to the question "when can you have X done?" is
not "what is the earliest date by which you just might be able to have X done?" It is
"what is a reasonable date, allowing for the usual unexpected problems, by which X
can reliably be finished?" People tend to give optimistic estimates -- partly because of
the iceberg principle, and partly from social pressure to appear on the ball.
Denial Problems
Denial Schedule
1. Human nature to want to interpret and report things optimistically
- Alice: I think there's huge monster behind this door.
- Bob: Let's not look in there.
2. Quality of code is not immediately apparent

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

- With most systems, we observe the obvious part sticking above the water line and
use that view in our mental models. Most of the complexity is not visible.
Tend To Plan in terms of External View
- When thinking about a system, we tend to use the external view for the various
components. (I believe this is an inherent feature of using a brain which must use
conceptual simplifications to think about a complex world.)
Underestimate
- As a result, estimates invariably understate the total complexity. This happens every
time.
Allow Extra Time
- There will always be unexpected details and problems -- allow extra time for them.
This applies to any project (a paper, a widget, a movie, a vacation). There's
always more work in the details than is apparent from the external view of the
finished product.
- When making schedules, allow an extra 50% to deal with the inevitable
"unexpected" problems. "Under promise, over deliver"
e.g. Making List of Tasks
- Suppose you were to try to list out ahead of time all the tasks in a software project.
- 1. Make a list ahead of time of all the methods and issues which a piece of software
will need to deal with
- 2. Do you really think you've thought of everything in (1)? All the unexpected
bugs? All the blind alleys? It's guaranteed that there will be issues which are only
revealed during the implementation. Could add a blanket "things we haven't
thought of in this list" item to the list.
When Can you have X done?
When planning a project, the answer to the question "when can you have X done?" is
not "what is the earliest date by which you just might be able to have X done?" It is
"what is a reasonable date, allowing for the usual unexpected problems, by which X
can reliably be finished?" People tend to give optimistic estimates -- partly because of
the iceberg principle, and partly from social pressure to appear on the ball.
Denial Problems
Denial Schedule
1. Human nature to want to interpret and report things optimistically
- Alice: I think there's huge monster behind this door.
- Bob: Let's not look in there.
2. Quality of code is not immediately apparent

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me

Denial vs. Observed
• Accept the observed. You just played with your own application for 5 minutes. What is
it trying to tell you? "Denial" = see what you wish were happening, instead of what is
happening
• You want things to be going well
- It's human nature to ignore or re-interpret data which suggests that things are going
poorly. It's human nature to put the best spin on things when reporting to others.
• "I'll have that working really soon"
- If it keeps not working and that's what things are depending on, put more people on
it.
• People
- If someone is not getting the job done, you need to move your staffing around.
Excuses don't cut it. Double people up on the hard problems -- your goal is to
build the best app you can with the people you have. Do not waste time getting
mad (or feeling guilty). Set everyone up so they can contribute.
• "Denial" schedule -> Working on the wrong things
- if you are slipping, then you need to cut features early. The denial schedule leaves
you at the end with too many features, each 70% done.
- If someone on the team is in over their head, the sooner everyone involved accepts
that and makes changes to give them some help, the better off everyone is going
to be.
- The sooner you realize what's going on, the better.
• Scenario
- Mon: "Ok, let's try to integrate on Wed"
- Wed: (The Foo module crashes) "The Foo module has one little problem in it, but it
basically works, I'll have it done by Thurs."
- Thurs: (The Foo module is still crashing)
- The Objective Assessment moment: "The Foo module is our current biggest worry:
(1) Jane, you start helping Bob with the Foo module tonight. (2) The both of you
make time to go to office hours early tomorrow and get the TA to look at the
design. We need it to be fixed."

__________________
.....................................
''''''Rajesh''''''
Ants. . . . . . Like me