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

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

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.

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.

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

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

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?

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

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?

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