1. CSE403 Software Engineering Autumn 2000 Dead or Alive
CSE 403 Autumn 2000
CSE403 Software Engineering Autumn 2000 Dead or Alive
Gary Kimura
Lecture #26
November 27, 2000
November 27, 2000

2. Today Weekly reports due today and again this Friday
Posted on the class web is a final project demos and individual reports page
Please read it and be prepared for the end of the quarter
Guest speakers next three lectures
Possible quiz #4 material
Finish when to call it a day
Is the system dead or alive?
Evaluations

3. A typical day near the end
5 AM results are starting to be gathered for the previous night stress run
7 AM release of the previous nights stress results. Developers then have until noon or so to debug all the crashed machines. Sometimes you need to keep the machine a lot longer.
8 AM meeting of the development team managers looking at the nightly stress results and new bugs review (they decide which bugs need to be fixed, and when to ship the product). Near the very end this becomes a twice a day meeting
10 AM to 3 PM the build lab is willing to accept any bug fixes for approved showstopper bugs
5 PM dinner is served
6 PM the next build is released and everyone installs the new system and starts up stress, and those with showstopper bugs continue to work.

4. Finally
When it is finally decided to ship the product then the bits go into escrow as the golden media is produced and manufacturing starts ramping up. Testing continues and if necessary the bits can be recalled from escrow and the release done over again.
Work continues on the subsequent release for the various server editions and international language versions.

5. Ancillary issues Media hype Competitive pressure Timing the release
Setting expectations
Beta previews
Getting beta customer testimonials might be important
Competitive pressure
Market share before quality
First one defines the market and grabs market share even with junk
The followers often play catch-up with mixed success (unless you are a monopoly)
Timing the release
When do we get paid and are we ready for the IPO?
Major release vs. minor release
Big delta or small delta
Customer perception based on version number
Some IHV contracts are based on version number
Where to have the ship party

6. Dead or just slow
How do you tell if a system is really dead or just show?
Some cases are really obvious
Bugcheck (the window’s blue screen of death)
Slowly drawing a new screen
Slowly making progress
But some cases are less obvious
A struck mouse or one that moves slowly
Non responsive to Ctrl-C
A pegged CPU metter
A disk that is being pounded upon
Distributed application are even harder to diagnose

7. Who cares
From a developer viewpoint does it really matter if a system is slow?
From a customer viewpoint does it really matter if a system is slow versus dead? And how would the customer tell the two apart?

8. Where to look for solutions in slow systems
Infinite loops
Thrashing
Beware of secondary processes that are chewing up all the resources.
Priority inversion makes some systems look pretty dead
Illegal process state

9. Beyond our control What if the fix is beyond the developers control?
What if the customer is too cheap to buy a faster larger machines?

10. Evaluations
If possible please offer specific suggestions on how I can improve the class O
Do you think the class needs a formal text book?
Is it weighted too heavily to the class project?
How can I make the class better next time?
How can I improve my own teaching style?
What do I do that I should stop doing?
What do I do that I should continue doing?
Please be honest