Software Development Graveyard

278 views
224 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
278
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Software Development Graveyard

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

×