The Development Graveyard: How Software Projects Die

The Development Graveyard:How Software Projects Die

Dr. Adam Kolawa - CEO, Parasoft

Parasoft Proprietary and Confidential

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


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


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


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


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


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.)


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


II: Death-defying development rules

What could have saved this project? Enforce time-consuming practice with support

and understanding


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


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

III: What sent it to the grave?


III: Death-defying development rules


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


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


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


IV: Death-defying development rules


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


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


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

V: What saved us from the grave?

The Development Graveyard: How Software Projects Die

Technology

Transcript of The Development Graveyard: How Software Projects Die