Myths

746 views
622 views

Published on

test doc

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
746
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
7
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Churchill Joke -- “Churchill was asked if he didn’t start to get a big head because…” Woody Allen “We need the eggs” joke? -- seems appropriate for the “myths” topic Need to get Albertus font installed on this machine
  • These mistakes have been made so often and by so many different people that they deserve to be called ‘classics’.
  • These mistakes have been made so often and by so many different people that they deserve to be called ‘classics’.
  • These mistakes have been made so often and by so many different people that they deserve to be called ‘classics’.
  • From “A Correlational Study of the CMM and Software Development Performance” Dr. Patricia K. Lawlis, Capt. Robert M. Flowe, and Capt. James B. Thordahl , CrossTalk, September 1995
  • From “A Correlational Study of the CMM and Software Development Performance” Dr. Patricia K. Lawlis, Capt. Robert M. Flowe, and Capt. James B. Thordahl , CrossTalk, September 1995
  • From “A Correlational Study of the CMM and Software Development Performance” Dr. Patricia K. Lawlis, Capt. Robert M. Flowe, and Capt. James B. Thordahl , CrossTalk, September 1995
  • Message: it’s more important to get the right requirements than...
  • Message: it’s more important to get the right requirements than...
  • 5 Why did I change the subtitle of the talk to “Taming Wild Software Schedules?” Why not just call it “Developing as Fast as Possible?” It’s because it turns out that there is a lot more to rapid development than all-out development speed.  Kinds of Effective, Schedule-Oriented Practices  Speed-Oriented Practices (Do 12 month project in 9 months) ( Evolutionary Prototyping, RDLs, Timeboxing, Outsourcing ) These are clearly needed, as the introduction illustrated.  Schedule-Risk Practices (Contain 12 month project to 12 months) ( Change Board, Top 10 risks list, Design for Change ) These practices are for damage containment—for preventing big overruns Visibility-Oriented Practices ( Evidence that 12 month project will take 12 months) ( Miniature Milestones, Staged Delivery, Project Status on Intranet )  This is how organizations choose ill-suited practices They choose speed-oriented practices when what they really need to do is manage risk better, etc. The bottom line is that you need to employ all three kinds of practices within a well-considered framework
  • 5 Why did I change the subtitle of the talk to “Taming Wild Software Schedules?” Why not just call it “Developing as Fast as Possible?” It’s because it turns out that there is a lot more to rapid development than all-out development speed.  Kinds of Effective, Schedule-Oriented Practices  Speed-Oriented Practices (Do 12 month project in 9 months) ( Evolutionary Prototyping, RDLs, Timeboxing, Outsourcing ) These are clearly needed, as the introduction illustrated.  Schedule-Risk Practices (Contain 12 month project to 12 months) ( Change Board, Top 10 risks list, Design for Change ) These practices are for damage containment—for preventing big overruns Visibility-Oriented Practices ( Evidence that 12 month project will take 12 months) ( Miniature Milestones, Staged Delivery, Project Status on Intranet )  This is how organizations choose ill-suited practices They choose speed-oriented practices when what they really need to do is manage risk better, etc. The bottom line is that you need to employ all three kinds of practices within a well-considered framework
  • 5 Why did I change the subtitle of the talk to “Taming Wild Software Schedules?” Why not just call it “Developing as Fast as Possible?” It’s because it turns out that there is a lot more to rapid development than all-out development speed.  Kinds of Effective, Schedule-Oriented Practices  Speed-Oriented Practices (Do 12 month project in 9 months) ( Evolutionary Prototyping, RDLs, Timeboxing, Outsourcing ) These are clearly needed, as the introduction illustrated.  Schedule-Risk Practices (Contain 12 month project to 12 months) ( Change Board, Top 10 risks list, Design for Change ) These practices are for damage containment—for preventing big overruns Visibility-Oriented Practices ( Evidence that 12 month project will take 12 months) ( Miniature Milestones, Staged Delivery, Project Status on Intranet )  This is how organizations choose ill-suited practices They choose speed-oriented practices when what they really need to do is manage risk better, etc. The bottom line is that you need to employ all three kinds of practices within a well-considered framework
  • Myths

    1. 1. 10 Myths of Rapid Development Steve McConnell © 2000-2001. All Rights Reserved. Construx Delivering Software Project Success
    2. 2. Myth #1 Rapid Development is a New Issue
    3. 3. Rapid Development Has Been an Issue for 30 Years! <ul><li>Gene Bylinsky (1967) “All significant programming problems turn out to be emergencies&quot; </li></ul><ul><li>Fred Brooks (Mythical Man-Month, 1975): </li></ul><ul><li>“ More software projects have gone awry for lack of calendar time than all other causes combined.” </li></ul>
    4. 4. Why Do We Need Rapid Development? <ul><li>1. Developers estimate the schedule </li></ul><ul><li>2. Marketing cuts the schedule by 50% </li></ul><ul><li>3. Team skips requirements because there isn’t enough time for it </li></ul><ul><li>4. Team skips design because there isn’t enough time for it </li></ul><ul><li>5. Team begins coding and testing </li></ul>Let’s walk our way through a typical project:
    5. 5. Why Do We Need Rapid Development? (cont.) <ul><li>7. Team codes “quick and dirty” solutions to design problems </li></ul><ul><li> The project gets later </li></ul>6. Team adds features that were missed when requirements work was skipped  The project gets later
    6. 6. Why Do We Need Rapid Development? (cont.) <ul><li>After many more of these cycles... </li></ul><ul><li>9. Team releases the software over budget and with less functionality than desired … </li></ul><ul><li>close to the time developers originally estimated in Step 1! </li></ul>8. Team fixes the bugs created by the quick and dirty workarounds  The project gets later
    7. 7. Myth #2 Productivity Is About the Same at Every Company
    8. 8. Productivity Varies a Lot <ul><li>20:1 variations in productivity between different programmers </li></ul><ul><li>10:1 variations in productivity between different companies working in the same industries </li></ul><ul><li>Productivity is a learned characteristic and can be changed </li></ul>
    9. 9. Myth #3 Working Hard Promotes Rapid Development
    10. 10. Old Saying <ul><li>“ It’s better to work smart than to work hard” </li></ul>
    11. 11. Microsoft Changed the Old Saying to... <ul><li>“ It’s better to work smart and hard” </li></ul>
    12. 12. Amazon.com Changed the Saying to... <ul><li>“ It’s better to work smart and hard and long!” </li></ul><ul><li>This is the state of most of the software world today </li></ul>
    13. 13. Reality Check: Project Resolutions
    14. 14. Reality Check: Typical Project Resolutions <ul><li>Only about 25% of all projects are delivered on time </li></ul><ul><li>About 75% of all projects are either late or cancelled </li></ul><ul><li>As many projects are cancelled as delivered on time </li></ul>
    15. 15. Bottom Line <ul><li>Working hard and smart usually means working dumb ! </li></ul><ul><li>The average project spends 40-80% of its budget on unplanned rework (defect corrections)--that is working dumb </li></ul><ul><li>The average project burns out its developers--that is working dumb </li></ul><ul><li>“Work smart, not hard” turns out to be the right idea after all </li></ul>
    16. 16. Myth #4 Short Estimates Produce Short Projects
    17. 17. Effect of Estimation Accuracy 100% >100% < 100% Target as a Percentage of Nominal Estimate Overestimation Underestimation Cost Effort Schedule Linear impact due to Parkinson’s Law Non-linear impact due to planning errors, upstream defects, high-risk practices
    18. 18. Short Estimates Increase Cost and Schedule <ul><li>Short estimates lead to planning mistakes and quality mistakes that make projects take longer </li></ul><ul><li>Underestimation is a common, severe problem </li></ul><ul><li>Very little estimation is actually done--mostly target setting </li></ul><ul><li>Part of achieving true rapid development is making software estimates rational </li></ul>
    19. 19. Improved Estimation From a set of U.S. Air Force projects
    20. 20. Improved Estimation From a set of U.S. Air Force projects
    21. 21. Improved Estimation From a set of U.S. Air Force projects
    22. 22. Improved Estimation <ul><li>Estimates must be made accurate before rapid development is achieved </li></ul><ul><li>This typically means increasing estimates (common practice is under-estimation) </li></ul><ul><li>This is hard because people want to believe they will develop software faster than they usually do </li></ul>
    23. 23. Myth #5 You Can Trade-Off Quality for Schedule or Cost
    24. 24. Cost of Quality <ul><li>For most projects, unplanned defect correction work is the largest cost driver (40-80% of total cost) </li></ul>
    25. 25. Late Defect Correction is Expensive Phase That a Defect Is Created Cost to Correct Requirements Architecture Detailed design Construction Requirements Architecture Detailed design Construction Release 50-200X 1X Phase That a Defect Is Corrected 50-200X 1X
    26. 26. Fix More Defects Earlier! Phase That a Defect Is Created Cost to Correct Requirements Architecture Detailed design Construction Requirements Architecture Detailed design Construction Release 50-200X 1X Phase That a Defect Is Corrected 50-200X 1X Fix Here Not Here
    27. 27. Reduce Defect Cost Increase! Phase That a Defect Is Created Cost to Correct Requirements Architecture Detailed design Construction Requirements Architecture Detailed design Construction Release 10X? 1X Phase That a Defect Is Corrected 10X? 1X
    28. 28. <ul><li>A focus on quality typically reduces effort and shortens schedule </li></ul>Cost of Quality
    29. 29. Cost of Quality <ul><li>When organizations focus on quality, they typically improve in all categories at once </li></ul><ul><li>Typical results (13 company study): </li></ul><ul><ul><li>Duration: 3.5 years </li></ul></ul><ul><ul><li>Productivity gain per year: 35% (186% total) </li></ul></ul><ul><ul><li>Schedule reduction per year: 19% (52% total) </li></ul></ul><ul><ul><li>Post-release defect report reduction per year: 39% (82% total) </li></ul></ul>
    30. 30. Myth #6 Customers and Management Want Rapid Development
    31. 31. Speed-Oriented Practices 6 Months: Nominal Schedule Competitor will release next version of their product Average Project “ Rapid” Project Risk of Overrun
    32. 32. Risk-Oriented Practices 6 Months: Nominal Schedule Beginning of Holiday Sales Season or Trade Show Average Project “ Rapid” Project Risk of Overrun
    33. 33. Visibility-Oriented Practices 6 Months: Nominal Schedule Risk of Overrun Average Project “ Rapid” Project Project review meeting where project is cancelled due to general nervousness
    34. 34. Myth #7 Smart Programmers Exert the Biggest Productivity Impact
    35. 35. A Lot of Truth to This <ul><li>20:1 difference in productivity among programmers with similar experience levels </li></ul><ul><li>Similar differences in design quality, program size, debugging performance, and debugging effectiveness </li></ul><ul><li>Programmer effectiveness varies tremendously </li></ul><ul><li>But ... </li></ul>
    36. 36. What if... <ul><li>A company has two star programmers… </li></ul><ul><li>That spend the whole project arguing with each other instead of working? </li></ul>
    37. 37. What if... <ul><li>A company’s star programmers are assigned to a project … </li></ul><ul><li>That’s ultimately cancelled? </li></ul>
    38. 38. What if… <ul><li>A company’s star programmers very quickly produce functionality … </li></ul><ul><li>That’s eventually cut from the product in order to meet a ship date? </li></ul>
    39. 39. Smart Individuals Don’t Guarantee Rapid Results <ul><li>We should not ignore the importance of smart programmers, but we must realize smart programmers are just one of many influences on a project’s schedule </li></ul><ul><li>Team cohesion matters at least as much </li></ul><ul><li>Organizational characteristics make a significant difference too </li></ul>
    40. 40. Myth #8 Software Processes Apply Only to Large, Old-Fashioned, Bureaucratic Projects
    41. 41. Telcordia (assessed at CMM Level 5) <ul><li>FCC mandated a change </li></ul><ul><li>Telcordia applied Level 5 practices to a project to… </li></ul><ul><ul><li>Make changes in 3,000 instructions </li></ul></ul><ul><ul><li>Spread through 40% of a code base </li></ul></ul><ul><ul><li>Consisting of 1 million LOC </li></ul></ul><ul><ul><li>No errors reported in next year of operation </li></ul></ul><ul><ul><li>Project took 9 hours from requirements analysis through regression testing </li></ul></ul>
    42. 42. Good Processes are Based on Common Sense Source: Telcordia Technologies: The Journey to High Maturity, Bill Pitterman, IEEE Software, July 2000 Quality Creative Chaos Mindless Chaos Mindless Bureaucracy Yes No Yes No Documented Process Common Sense
    43. 43. Myth #9 Systematic Development Approaches Hurt Morale
    44. 44. Effect of Process on Morale <ul><li>50 Company Survey: Percentage of people that rated their morale as “good” or “excellent”: </li></ul>
    45. 45. What’s Really Bad for Morale? <ul><li>Long hours </li></ul><ul><li>Unrealistic schedules </li></ul><ul><li>High stress </li></ul><ul><li>Feeling of low productivity </li></ul><ul><li>Working on poor-quality software </li></ul>
    46. 46. Reports from Process-Intensive Companies <ul><li>Cheyenne Mountain ATAMS Project: </li></ul><ul><li>“Engineers on the project viewed it as a positive experience. They felt the process brought out everyone's best performance, and they said they would be reluctant to develop software without it.” </li></ul>
    47. 47. Reports from Process-Intensive Companies <ul><li>Telcordia (CMM Level 5): </li></ul><ul><li>“ Our software business has doubled, our profits have grown, and we have measured customer satisfaction at better than 95%. Our on-time delivery is 98% to 99% over the last three years. Our employee turnover rate is in low single digits.” </li></ul>
    48. 48. Myth #10 Development in “Internet Time” is Faster Than Old Fashioned Development
    49. 49. Key Question <ul><li>How is development in “Internet Time” different from previous kinds of development? </li></ul>
    50. 50. Traditional Estimate Effort Program Size Traditional Estimated Effort
    51. 51. Traditional Results Effort Program Size Actual Effort Traditional Estimated Effort
    52. 52. “Internet Time” Estimate Traditional Estimated Effort Effort Program Size “ Internet Time” Estimate Actual Effort
    53. 53. Internet Time Results Effort Program Size Internet Time Effort Traditional Estimated Effort “ Internet Time” Estimate
    54. 54. What’s Really Changed?
    55. 55. 1980 <ul><li>Mainframe developers worked long hours </li></ul><ul><li>They bought their own pizza </li></ul>
    56. 56. 1990 <ul><li>PC developers worked long hours </li></ul><ul><li>“Enlightened management” bought their pizza </li></ul>
    57. 57. 2000 <ul><li>Web developers work long hours </li></ul><ul><li>Venture capitalists buy their pizza! </li></ul>
    58. 58. 2001 <ul><li>With widespread cost cutting... </li></ul><ul><li>We’re back to buying our own pizza! </li></ul>
    59. 59. Conclusions <ul><li>Rapid development is possible! </li></ul><ul><li>Some companies are developing amazingly rapidly (e.g., Telcordia) </li></ul><ul><li>Achieving rapid development requires a combination of process and common sense </li></ul><ul><li>It requires a commitment to avoid the problems associated with the 10 myths </li></ul>
    60. 60. <ul><li>Consulting </li></ul><ul><ul><li>Project Reviews </li></ul></ul><ul><ul><li>Requirements Workshops </li></ul></ul><ul><ul><li>Project Planning </li></ul></ul><ul><ul><li>Coaching </li></ul></ul><ul><ul><li>Organizational Assessments </li></ul></ul><ul><li>Training </li></ul><ul><ul><li>Public Seminars </li></ul></ul><ul><ul><li>Onsite Seminars </li></ul></ul><ul><ul><li>Training Needs Assessment </li></ul></ul><ul><ul><li>Customized Curriculums </li></ul></ul><ul><ul><li>Executive Briefings </li></ul></ul>Construx Services <ul><li>Software Projects </li></ul>

    ×