This presentation explores the reasons why software projects are significantly more difficult to manage than other types of projects. Software-specific issues related to scope, resources, and time are explored, as well as how software projects differ from other projects in the physical world. An argument for why software constitutes a “Wicked Problem” is expanded, and numerous software development myths are attacked with real-world anecdotes and solutions.

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

31. TimeMarchesAt
AConstantRate

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

41. FeaturesCanBe
CutToResolve
Cost&Schedule
Issues

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

49. Lotsofsoftware
development
“myths”have
takenonapatina
oftruth.

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