The document discusses several case studies illustrating how software projects fail due to changing requirements, misguided mandates, ineffective prototyping, hasty rescue efforts, and scope creep. It emphasizes the importance of clear specifications, appropriate management practices, and adhering to development rules to prevent project failure. The author, Dr. Adam Kolawa, provides insights into best practices that could have saved the doomed projects highlighted in the tales.

1. The Development Graveyard:
How Software Projects Die
Dr. Adam Kolawa - CEO, Parasoft
October 29, 2009

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 principles
Parasoft Proprietary and Confidential

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 meetings
Parasoft Proprietary and Confidential

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 live
Parasoft Proprietary and Confidential

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 hadn't yet been scoped out
Development of the new application began
without requirements
Requirements were changing for 5 years—with
no end in sight
Parasoft Proprietary and Confidential

6. I: Death-defying development rules
What 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 project
Parasoft Proprietary and Confidential

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. 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 next
Parasoft Proprietary and Confidential

9. II: Death-defying development rules
What could have saved this project?
Enforce time-consuming practice with support
and understanding
Parasoft Proprietary and Confidential

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 start
Parasoft Proprietary and Confidential

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 developers
Parasoft Proprietary and Confidential

12. III: Death-defying development rules
What 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 debugging
Parasoft Proprietary and Confidential

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 Agile
Parasoft Proprietary and Confidential

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 cycles
Parasoft Proprietary and Confidential

15. IV: Death-defying development rules
What 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 prematurely
Parasoft Proprietary and Confidential

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 them
Parasoft Proprietary and Confidential

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
iteration
Parasoft Proprietary and Confidential