The Development Graveyard: How Software Projects Die

433 views

Published on

Learn the top 5 reasons why software projects fail. The scariest part is that the failure causes are easily avoidable - yet as IT professionals, we continue to make life more difficult than it really needs to be.

Published in: Technology
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
433
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
10
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

The Development Graveyard: How Software Projects Die

  1. 1. The Development Graveyard: How Software Projects Die Dr. Adam Kolawa - CEO, Parasoft
  2. 2. Outline <ul><li>4-5 tales – depending on time </li></ul><ul><li>For each tale, we will explore </li></ul><ul><ul><li>Details of the doomed project </li></ul></ul><ul><ul><li>Death-defying development rules that could have saved the project </li></ul></ul><ul><ul><li>How to apply these death-defying principles </li></ul></ul>
  3. 3. I: Doomed by changing requirements <ul><li>Submitted by Claude Hebert Jr. </li></ul><ul><li>Corporate decided to replace a legacy app for a large distribution business </li></ul><ul><ul><li>New app - Estimated to take 2 years with additional staff </li></ul></ul><ul><ul><li>Migration - Estimated to take < 6 months with the in-house staff (including 2 months of testing) </li></ul></ul><ul><ul><li>Corp. wanted a brand new system, not migration </li></ul></ul><ul><li>During implementation, requirements were constantly changing </li></ul><ul><ul><li>One day a module would be done and ready for testing, the next day it would be broken because a business rule changed </li></ul></ul><ul><ul><li>Constantly redoing data mapping, scripting, testing </li></ul></ul><ul><li>Weekly project meetings, daily Scrum meetings </li></ul>
  4. 4. I: Doomed by changing requirements <ul><li>By end of 4 th year: </li></ul><ul><ul><li>Less than $.5 million left </li></ul></ul><ul><ul><li>Group size expanded </li></ul></ul><ul><li>After 4 years and 8 months </li></ul><ul><ul><li>Down to the last dollar </li></ul></ul><ul><ul><li>Requirements still changing </li></ul></ul><ul><ul><li>No usable results </li></ul></ul><ul><ul><li>Projected over a year until completion – assuming no more requirement changes </li></ul></ul><ul><li>After 5 years </li></ul><ul><ul><li>5 million LOC, but no product </li></ul></ul><ul><ul><li>Decided to migrate the legacy app after all </li></ul></ul><ul><li>6 weeks later, the migrated app was in testing </li></ul><ul><li>4 weeks later, it went live </li></ul>
  5. 5. I: What sent it to the grave? <ul><li>Corporate mandates and budgeting without any investigation or metrics </li></ul><ul><li>Outside consultant company hired to manage a project that hadn't yet been scoped out </li></ul><ul><li>Development of the new application began without requirements </li></ul><ul><li>Requirements were changing for 5 years—with no end in sight </li></ul>
  6. 6. I: Death-defying development rules <ul><li>What could have saved this project? </li></ul><ul><li>Never change 2 things at once (architecture and functionality) </li></ul><ul><li>Never break the product completely; move piece by piece to a new architecture, test as you go </li></ul><ul><li>Don’t waste time in meetings </li></ul><ul><li>Never build without a set spec, tasks connected to requirements </li></ul><ul><li>Don’t start too ambitiously and over-engineer </li></ul><ul><li>Set the stage for informed decision making by people who really understand the project </li></ul>
  7. 7. II: Doomed by mandates <ul><li>Management imposed a new development practice on development </li></ul><ul><li>This situation: Trying to enforce Java coding standards with a open source static analysis tool </li></ul><ul><li>Other common situations </li></ul><ul><ul><li>Practices: static analysis, unit testing, code review </li></ul></ul><ul><ul><li>Demonstrate regulatory compliance (FDA, PCI, Section 508…) </li></ul></ul><ul><ul><li>Drive internal security and quality initiatives </li></ul></ul><ul><ul><li>Ensure consistency/quality from outsourcers </li></ul></ul><ul><ul><li>Achieve process improvement (CMMI, Six Sigma, etc.) </li></ul></ul>
  8. 8. II: What sent it to the grave? <ul><li>A productivity nightmare ensued—and the static analysis practice decayed in a matter of weeks </li></ul><ul><li>The team was overwhelmed by work </li></ul><ul><ul><li>Big bang implementation – 100s of rules, entire code base </li></ul></ul><ul><ul><li>Long lists of things to fix </li></ul></ul><ul><ul><li>Not sure who was responsible for fixing what </li></ul></ul><ul><ul><li>No time to fix things </li></ul></ul><ul><ul><li>Disrupted workflow, delayed project </li></ul></ul><ul><li>The team was spinning its wheels trying to determine how to proceed </li></ul><ul><ul><li>No clear definition of what was expected </li></ul></ul><ul><ul><li>Not sure what to do next </li></ul></ul>
  9. 9. II: Death-defying development rules <ul><li>What could have saved this project? </li></ul><ul><li>Enforce time-consuming practice with support and understanding </li></ul>
  10. 10. III: Doomed by prototyping not productizing <ul><li>Years ago, our own developers were working on a new defect prevention technology </li></ul><ul><li>Prototyping was necessary… because the technology was so new, specs could not be clearly defined from the start </li></ul>
  11. 11. <ul><li>The project was paralyzed by too long in prototyping </li></ul><ul><ul><li>Expected use cases worked—but little else did </li></ul></ul><ul><ul><li>Like a typical “version 1” release—performs a limited scope of technology, but not robust </li></ul></ul><ul><ul><li>Developed by trying to determine what they missed and retrofit it in </li></ul></ul><ul><ul><li>Digressed into “debugging-driven development” </li></ul></ul><ul><li>Didn’t shift soon enough from prototyping to productizing with a group of solid developers </li></ul>III: What sent it to the grave?
  12. 12. III: Death-defying development rules <ul><li>What could have saved this project? </li></ul><ul><li>To create a product (not just a prototype), you need to understand functional milestones, build and maintain a regression test suite </li></ul><ul><li>Don’t let rough, self-confident developers take over the group </li></ul><ul><li>Ensure that developers don’t hack the code, taking shortcuts that result in fragile, brittle implementations </li></ul><ul><li>Bake quality in instead of trying to test problems out with debugging </li></ul>
  13. 13. IV: Doomed by hasty rescue efforts <ul><li>This organization was behind on their project, and desperately wanted to catch up </li></ul><ul><li>They tried… </li></ul><ul><ul><li>Adding developers </li></ul></ul><ul><ul><li>Changing the software development process to Agile </li></ul></ul>
  14. 14. IV: What sent it to the grave? <ul><li>Adding developers did not help </li></ul><ul><ul><li>Ended up with more meetings than code </li></ul></ul><ul><ul><li>New developers were overwhelmed; the team assigned tasks to them, relied on them, and were ultimately delayed and disappointed </li></ul></ul><ul><li>Changing the process didn’t help </li></ul><ul><ul><li>Most teams need to behave differently at different phases </li></ul></ul><ul><ul><li>More Agile during prototyping, slower cycles when implementing more detailed work later in the project </li></ul></ul><ul><li>Forcing it to QA prematurely also did not help </li></ul><ul><ul><li>Creates seemingly endless cycles </li></ul></ul>
  15. 15. IV: Death-defying development rules <ul><li>What could have saved this project? </li></ul><ul><li>Only a fixed amount of developers can really deal with the code—too many developers requires too much communication </li></ul><ul><li>Don’t waste time in meetings </li></ul><ul><li>Assign tasks based on knowledge </li></ul><ul><li>Don’t expect a miracle from changing the software development process </li></ul><ul><li>Too large of a team leads to bad interfaces, over-abstraction </li></ul><ul><li>Don’t pass code to QA prematurely </li></ul>
  16. 16. V: Doomed by distraction and scope creep <ul><li>The final tale: How I personally drove projects towards the dark side </li></ul><ul><li>On Mondays, I would tell development groups all about the product ideas I had over the weekend </li></ul><ul><li>Developers would then stop in their tracks, change direction, and try to start implementing these ideas </li></ul><ul><li>This constantly disrupted their schedules </li></ul><ul><li>I didn’t want them to act on these ideas—I just wanted to get them out so I did not forget them </li></ul>
  17. 17. V: What saved us from the grave? <ul><li>Concerto made me realize that this was driving us towards the grave </li></ul><ul><li>Now, we add these ideas to a list </li></ul><ul><ul><li>Stored as requirements or feature requests </li></ul></ul><ul><li>They remain on the list, which is reviewed before the start of each new iteration </li></ul><ul><ul><li>Ideas are archived </li></ul></ul><ul><ul><li>We see if ideas stand the test of time </li></ul></ul><ul><li>The best ideas are scheduled for a logical iteration </li></ul>

×