Why Is Managing Software So Hard?
1 like688 views
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.
Why Is Managing Software So Hard?
- 1. WHY IS SOFTWARE DEVELOPMENT SO HARD? SEI 2015 Munich Michael Lamont lamont@post.harvard.edu
- 2. Dragon’sTriangle Mysterious area off coast of Japan where ships sink, planes crash, and all kinds of weird things happen
- 3. Software BalancingAct Successfully complete a project plan while meeting changing demands and constraints
- 4. Unreasonable Constraints • Set schedules & budgets without a detailed design • Estimations performed without input from developers • Ignoring interlocking relationships between cost, schedule, and features
- 5. Three Sides of Software Dragon’s Triangle • Scope • Resources • Schedule
- 6. SoftwareProject Failure Interrelated problems of “Dragon’s Triangle” cause a significant number of software projects to disappear
- 7. Non-Software Industries Is the grass greener elsewhere?
- 8. Construction Trade in your Nerf 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 often lend 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 change to original plans, no profit for contractor • Changes to original blueprint are virtually guaranteed • Profit comes from charging for changes
- 12. Softwareis AlwaysNew Every software system is 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’s impossible to predict the problems you’ll face before you’re well into the development process.
- 15. Development teams love to work on shiny new projects, but complexity lurks within
- 16. Physical objects have tactile properties – software does not.
- 17. Comparison of Hardware/Software Properties 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 real world, following sequential steps gives us incremental completion we can experience and evaluate
- 20. In early stages of software development, all we have are design and architecture documents to experience.
- 21. SoftwareIsA LeapofFaith All stakeholders have to trust the process, and believe progress is being made.
- 22. Software engineering’s track record at anticipating and mitigating risks isn’t great compared to engineering in the physical world.
- 23. Engineering in the physical 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’s easy to get forced into dealing with simultaneous problems: • Scheduling • Cost • Features
- 25. 3 Points of the Dragon’s Triangle Scope Resources Schedule
- 26. 3 Points of the Dragon’s Triangle Scope Resources Schedule
- 27. Softwareprojects aren’t deterministic There isn’t a linear relationship between staffing and schedule, and the relationship can even go inverted (adding more people makes the project take longer)
- 28. 7 8 9 10 11 12 1 2 3 4 5 6
- 29. 7 8 9 1 2 3 4 5 6
- 30. 1 2 3 4 5 6
- 33. FeatureCreep The list of required features always seems to grow longer as a project progresses – never shorter.
- 34. The“SadTruths” NegativelyImpact Morale Dev team sees the size of the project increase, without a corresponding increase in time and resources
- 35. HiringNewPeople MakesThings Worse New employees (or even 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 for quickly spending ridiculous amounts of resources to force a project to completion • Caused by the software manager’s failings
- 39. Deterministic Problem:Hauling Dirt • Adding more people gets the job done faster • But not really: still scaling problems past a certain point
- 40. SoftwareIsn’t Deterministic • No way to 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
- 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 the affected 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 forth by 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
- 50. Software Development Myths 1. Software is easier to change than hardware
- 51. Large-scale projects in the physical world undergo intensive planning before anyone touches a shovel
- 52. With software, it’s too 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 provide a useful template for software maintenance. Careful records are kept of every issue and action taken, and analyzed to improve results.
- 55. Without metrics, processes, and clearly 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 remove other 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 comments fail 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 assembly line 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 used high-quantity, low- quality production processes
- 62. Post-war Japanese industry focused on high quality products at the expense of quantity.
- 63. Testing only tells you 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 always depended 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’t testing 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 make unhappy 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 rather be coding, don’t deal effectively with HR issues, and are generally miserable.
- 72. PayShouldBeTied toValue,Not Position Many managers at successful firms 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 evolved over time to work in both ordinary and extraordinary circumstances.
- 76. Example:Out-of- stockAirplane Parts Passenger aircraft manufacturers have processes to 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 to offer a product in a new market niche usually grabs 60%- 80% share.
- 79. LockUp Difficult to compete in a saturated market – “rip and replace.” …But how long does it really take to put together some reasonable processes?
- 80. “LandRush” Development Actually takes more time 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 designed to 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 systems introduce 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 managers are 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 stories lack 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 forward no 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 slip because of a single catastrophic event.
- 89. DucksKill SoftwareProjects A single bite from a duck won’t kill you, and a small schedule issue won’t kill a software project.
- 90. Actually,LOTSof DucksKillSoftware Projects A missed delivery or 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 of Software Scope Resources Schedule
- 92. Software ManagementIsn’t AnExactScience No definite right or 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