Download as PDF, PPTX
Uploaded byMichael Lamont
Why Is Managing Software So Hard?
The document discusses the challenges of software development, emphasizing the 'dragon's triangle' of scope, resources, and schedule, which contribute to project failures. It contrasts software development's inherent unpredictability and complexity with more structured industries like construction, highlighting issues like feature creep and the impact of management decisions on team morale. Additionally, it dispels common myths about software engineering, asserting the importance of processes, quality assurance, and careful planning to achieve successful project outcomes.
More Related Content
Similar to Why Is Managing Software So Hard?
Why Is Managing Software So Hard?
- 1. WHY IS SOFTWARE DEVELOPMENTSO HARD? SEI 2015 Munich Michael Lamont [email protected]
- 2. Dragon’sTriangle Mysterious area offcoast of Japan where ships sink, planes crash, and all kinds of weird things happen
- 3. Software BalancingAct Successfully complete a projectplan while meeting changing demands and constraints
- 4. Unreasonable Constraints • Setschedules & budgets without a detailed design • Estimations performed without input from developers • Ignoring interlocking relationships between cost, schedule, and features
- 5. Three Sides ofSoftware Dragon’s Triangle • Scope • Resources • Schedule
- 6. SoftwareProject Failure Interrelated problems of “Dragon’sTriangle” cause a significant number of software projects to disappear
- 7. Non-Software Industries Is the grassgreener elsewhere?
- 8. Construction Trade in yourNerf gun for a nail gun? How much harder can it be?
- 9. Easy&Straight- Forward,Right? • Clear requirements •Expectations are easy to manage • Detailed plans (blueprint) • Well-established principles • Knowledgeable staff • On time, on scope, on budget • $$$ for everyone!
- 10. NotActuallyThat Simple… • Construction doesn’t oftenlend itself to a cookie-cutter approach • Estimation can be more of a dark art than a simple process • Experience and intuition > science and engineering
- 11. HowContractors ActuallyGetPaid… • No changeto original plans, no profit for contractor • Changes to original blueprint are virtually guaranteed • Profit comes from charging for changes
- 12. Softwareis AlwaysNew Every software systemis different from those that came before, with its own set of challenges and issues.
- 13. There are real& substantial differences between building in the real world and building software.
- 14. When building software, it’simpossible to predict the problems you’ll face before you’re well into the development process.
- 15. Development teams love towork on shiny new projects, but complexity lurks within
- 16. Physical objects have tactileproperties – software does not.
- 17. Comparison of Hardware/SoftwareProperties Phenomenon Hardware Software Manufacture of exact duplicates A challenge Not a problem Wearing out with use or passage of time A major issue Not a problem Human sensory experiences Not a problem Not experienced Progress measured during construction Observable Observable only via a baseline process Cost, schedule, and planning Experienced physically Requires speculation and relatively high risk
- 18. We can see& touch our progress when building things in the physical world
- 19. In the realworld, following sequential steps gives us incremental completion we can experience and evaluate
- 20. In early stagesof software development, all we have are design and architecture documents to experience.
- 21. SoftwareIsA LeapofFaith All stakeholders haveto trust the process, and believe progress is being made.
- 22. Software engineering’s track recordat anticipating and mitigating risks isn’t great compared to engineering in the physical world.
- 23. Engineering in thephysical world is based on unchanging laws that make the future predictable. Lack of hard-and-fast principles in software world lets unpredictable major setbacks occur in moments.
- 24. When developing software, it’seasy to get forced into dealing with simultaneous problems: • Scheduling • Cost • Features
- 25. 3 Points ofthe Dragon’s Triangle Scope Resources Schedule
- 26. 3 Points ofthe Dragon’s Triangle Scope Resources Schedule
- 27. Softwareprojects aren’t deterministic There isn’t alinear relationship between staffing and schedule, and the relationship can even go inverted (adding more people makes the project take longer)
- 28. 7 8 910 11 12 1 2 3 4 5 6
- 29. 7 8 9 12 3 4 5 6
- 30. 1 2 34 5 6
- 31.
- 33. FeatureCreep The list ofrequired features always seems to grow longer as a project progresses – never shorter.
- 34. The“SadTruths” NegativelyImpact Morale Dev team seesthe size of the project increase, without a corresponding increase in time and resources
- 35. HiringNewPeople MakesThings Worse New employees (oreven old employees who are new to the project) require a long runway to get up to speed, and drain team resources in the process
- 36. Remedies/Repercussions in Hardware& Software Projects Situation Hardware World Software World Behind schedule Add people and/or equipment, and balance expense elsewhere Adding people makes matters worse, so cut features, which impacts customers and morale. Or go into Death March Mode. Over budget Stretch out delivery time; you might lose incentive fees. Adding people makes matters worse, so cut features, which impacts customers and morale. Or go into Death March Mode. Not all features will be delivered Renegotiate the contract; customer might get another vendor to finish the job. Reassess, focusing on customer’s “must have” features; customer expectations might impact opinion of results. Or go into Death March Mode.
- 37. Remedies/Repercussions in Hardware& Software Projects Situation Hardware World Software World Behind schedule Add people and/or equipment, and balance expense elsewhere Adding people makes matters worse, so cut features, which impacts customers and morale. Or go into Death March Mode. Over budget Stretch out delivery time; you might lose incentive fees. Adding people makes matters worse, so cut features, which impacts customers and morale. Or go into Death March Mode. Not all features will be delivered Renegotiate the contract; customer might get another vendor to finish the job. Reassess, focusing on customer’s “must have” features; customer expectations might impact opinion of results. Or go into Death March Mode.
- 38. “DeathMarch Mode” • Slang forquickly spending ridiculous amounts of resources to force a project to completion • Caused by the software manager’s failings
- 39. Deterministic Problem:Hauling Dirt • Adding morepeople gets the job done faster • But not really: still scaling problems past a certain point
- 40. SoftwareIsn’t Deterministic • No wayto predict how long it’ll take to identify and fix a specific defect • “Death March Mode” leads to mental fatigue, which leads to poor productivity and mistakes
- 41.
- 42. CuttingFeatures HurtsDevTeam Morale Developers are artists,and won’t be your biggest fan if you cut a feature they’ve poured their heart and soul into for months
- 43. IfYouHaveTo CutFeatures… • Reassure theaffected developers that their work is appreciated • Feature cuts are due to scheduling reasons, not the developers’ skill level or work product
- 44. “Wicked” Problems • Put forthby design theorist Horst Rittel • Describes a class of problems that don’t have bounded solutions • The more effort you put into solving the problem, the larger the problem becomes until infinity • Software development is a “wicked” problem
- 45. Criteria For “Wicked”Problems • Cannot be definitively stated • Software requirements change in unpredictable ways • No rule or guideline to determine when the problem is solved • Development on a product only stops when you run out of time or money • Solutions are “good” or “bad” – not “right” or “wrong” • Software provides thousands of ways to meet even the most detailed specifications • Some solutions are better than others, even though they all meet spec
- 46. Criteria For “Wicked”Problems • Cannot be definitively tested • No scientific way to accept or reject a specific software solution • Spec issues can be argued without clear rights and wrongs • Solutions are too big (i.e., expensive) to experiment with • Building multiple software systems and choosing the best is prohibitively expensive • There are unlimited solutions, and unlimited criteria for evaluation
- 47. Criteria For “Wicked”Problems • Every problem is unique • Symptomatic of higher-level problems • “Solving” one part of the problem can lead to unanticipated problems in other areas
- 48. Conclusion: Softwareisa “WickedProblem” Project success depends on: •Using what we know when the project starts • Using the data we gather over the course of the project • Trusting our data enough to use it to see the project through to completion
- 49.
- 50. Software Development Myths 1.Software is easier to change than hardware
- 51. Large-scale projects inthe physical world undergo intensive planning before anyone touches a shovel
- 52. With software, it’stoo easy to think we “see” the solution and start coding immediately, without really understanding the problem. Example: Y2K
- 53. Software Development Myths 1.Software is easier to change than hardware 2. Processes aren’t needed in “maintenance mode”
- 54. Aircraft maintenance processes providea useful template for software maintenance. Careful records are kept of every issue and action taken, and analyzed to improve results.
- 55. Without metrics, processes, andclearly defined methods, everyone loses. Especially our end users.
- 56. Software Development Myths 1.Software is easier to change than hardware 2. Processes aren’t needed in “maintenance mode” 3. Source code is self-documenting
- 57. Some developers actually removeother people’s comments from code. Argument: Documentation is going to be out of date soon, so I’m saving us time by removing it before that happens.
- 58. Arguments for removing commentsfail to take staff turnover issues into account. Fix with a simple requirement: every developer responsible for verifying comments are correct before checking in changes. Have QA do basic spot- checking to verify.
- 59. Software Development Myths 1.Software is easier to change than hardware 2. Processes aren’t needed in “maintenance mode” 3. Source code is self-documenting 4. Quality can be tested into a software system
- 60. Henry Ford’s rolling assemblyline built quality into the production process: • Break process into small steps • Execute each step perfectly • Quality inspections at key milestones during production
- 61. Pre-war Japanese industry usedhigh-quantity, low- quality production processes
- 62. Post-war Japanese industry focusedon high quality products at the expense of quantity.
- 63. Testing only tellsyou if quality is present – it doesn’t help increase a product’s quality. Quality products have a chance to be successful. Low-quality products end up where they belong: the scrap pile.
- 64. Software Development Myths 1.Software is easier to change than hardware 2. Processes aren’t needed in “maintenance mode” 3. Source code is self-documenting 4. Quality can be tested into a software system 5. We sell code, not analysis and design documents
- 65. Successful engineering has alwaysdepended on careful analysis, design, and planning. A carefully designed plan, agreed to by the development team, is much more likely to lead to a successful outcome.
- 66. Software Development Myths 1.Software is easier to change than hardware 2. Processes aren’t needed in “maintenance mode” 3. Source code is self-documenting 4. Quality can be tested into a software system 5. We sell code, not analysis and design documents 6. We don’t need QA – good programmers don’t make mistakes
- 67. QA’s job isn’ttesting software to find bugs – its job is to prevent bugs in the first place.
- 68. Software Development Myths 1.Software is easier to change than hardware 2. Processes aren’t needed in “maintenance mode” 3. Source code is self-documenting 4. Quality can be tested into a software system 5. We sell code, not analysis and design documents 6. We don’t need QA – good programmers don’t make mistakes 7. Increasing compensation increases performance
- 69. Increasing pay doesn’t makeunhappy developers happy. The company is signaling that they like the way things are going, and they aren’t going to make any changes. Make sure developers know any overwork scenario is a short-term situation
- 70. Software Development Myths 2.Processes aren’t needed in “maintenance mode” 3. Source code is self-documenting 4. Quality can be tested into a software system 5. We sell code, not analysis and design documents 6. We don’t need QA – good programmers don’t make mistakes 7. Increasing compensation increases performance 8. Rewarding managers with perks will make management positions desirable.
- 71. PerksDriveWrong KindOfPersonInto Management Managers would ratherbe coding, don’t deal effectively with HR issues, and are generally miserable.
- 72. PayShouldBeTied toValue,Not Position Many managers at successfulfirms are paid less than some of the engineers who work for them.
- 73. Software Development Myths 3.Source code is self-documenting 4. Quality can be tested into a software system 5. We sell code, not analysis and design documents 6. We don’t need QA – good programmers don’t make mistakes 7. Increasing compensation increases performance 8. Rewarding managers with perks will make management positions desirable 9. Processes are great, as long as you aren’t behind schedule
- 74. Balance Don’t abandon your processes,but don’t slavishly follow processes that don’t make sense for your situation.
- 75. GoodProcesses AreUsefulIn Emergencies Effective processes have evolvedover time to work in both ordinary and extraordinary circumstances.
- 76. Example:Out-of- stockAirplane Parts Passenger aircraft manufacturers have processesto get out-of- stock parts into customer hands ASAP. Manufacturing and quality processes are streamlined, but no steps are skipped.
- 77. Software Development Myths 4.Quality can be tested into a software system 5. We sell code, not analysis and design documents 6. We don’t need QA – good programmers don’t make mistakes 7. Increasing compensation increases performance 8. Rewarding managers with perks will make management positions desirable 9. Processes are great, as long as you aren’t behind schedule 10. We have to be first to market, and formal processes just slow us down
- 78. DefiniteFirst-To- MarketAdvantage First company tooffer a product in a new market niche usually grabs 60%- 80% share.
- 79. LockUp Difficult to competein a saturated market – “rip and replace.” …But how long does it really take to put together some reasonable processes?
- 80. “LandRush” Development Actually takes moretime to develop a marketable product in “Land Rush” mode than it will if you use defined processes to organize workflow and reduce bugs.
- 81. Software Development Myths 6.We don’t need QA – good programmers don’t make mistakes 7. Increasing compensation increases performance 8. Rewarding managers with perks will make management positions desirable 9. Processes are great, as long as you aren’t behind schedule 10. We have to be first to market, and formal processes just slow us down 11. We can tie together several COTS packages and mostly avoid writing new code
- 82. CommercialOff TheShelf(COTS) COTS packages are designedto solve a specific problem in a specific way – probably not yours. Using COTS makes your software the same as everyone else’s – why bother to develop it in the first place?
- 83. IntrinsicCOTS Issues Some popular COTS systemsintroduce significant latency into real-time and interactive software. Integration of multiple COTS systems isn’t as easy as you might think.
- 84. Software Development Myths 7.Increasing compensation increases performance 8. Rewarding managers with perks will make management positions desirable 9. Processes are great, as long as you aren’t behind schedule 10. We have to be first to market, and formal processes just slow us down 11. We can tie together several COTS packages and mostly avoid writing new code 12. Formal processes cause talented people to leave
- 85. AvoidingProcesses toAvoidChange Some poor managersare afraid of change, others are afraid that processes will reveal their poor leadership. Instituting formal processes usually improves development team morale (and productivity).
- 86. Process-Induced Failures All failure storieslack detail – the real story is that the dev team tried out a method, and had problems. Usually the problems would have been resolvable, but the software manager freaked when code didn’t start rolling out the door and abandoned the processes.
- 87. Maintaining ScheduleControl Time marches forwardno matter what you do. Too easy to not realize how far behind a software project is until it actually fails.
- 88. GodzillaDoesn’t KillSoftware Projects Schedules almost never slipbecause of a single catastrophic event.
- 89. DucksKill SoftwareProjects A single bitefrom a duck won’t kill you, and a small schedule issue won’t kill a software project.
- 90. Actually,LOTSof DucksKillSoftware Projects A missed deliveryor milestone is a “duck”. Lots of small schedule slips add up to big schedule slips. If enough ducks show up, your project’s dead.
- 91. Dragon’s Triangle ofSoftware Scope Resources Schedule
- 92. Software ManagementIsn’t AnExactScience No definite rightor wrong answers, processes, or solutions.
- 93. Key Take-Aways • Rules,principles, and experience in the physical world doesn’t often apply to software • Quality affects performance of both the product AND your team • Small scheduling slides very quickly add up to a large slip