Embed Size (px)
Citation preview
Dragon’s Triangle
Mysterious area off coast of Japan where ships sink, planes crash, and all kinds of weird things happen
Software Balancing Act
Successfully complete a project plan while meeting changing demands and constraints
Unreasonable Constraints • Set schedules & budgets without a detailed design
• Estimations performed without input from developers
• Ignoring interlocking relationships between cost, schedule, and features
Three Sides of Software Dragon’s Triangle • Scope
• Resources
• Schedule
Software Project Failure
Interrelated problems of “Dragon’s Triangle” cause a significant number of software projects to disappear
Non-Software Industries
Is the grass greener elsewhere?
Construction
Trade in your Nerf gun for a nail gun? How much harder can it be?
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!
Not Actually That 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
How Contractors Actually Get Paid…
• No change to original plans, no profit for contractor
• Changes to original blueprint are virtually guaranteed
• Profit comes from charging for changes
Software is Always New
Every software system is different from those that came before, with its own set of challenges and issues.
There are real & substantial differences between building in the real world and building software.
When building software, it’s impossible to predict the problems you’ll face before you’re well into the development process.
Development teams love to work on shiny new projects, but complexity lurks within
Physical objects have tactile properties – software does not.
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
We can see & touch our progress when building things in the physical world
In the real world, following sequential steps gives us incremental completion we can experience and evaluate
In early stages of software development, all we have are design and architecture documents to experience.
Software Is A Leap of Faith
All stakeholders have to trust the process, and believe progress is being made.
Software engineering’s track record at anticipating and mitigating risks isn’t great compared to engineering in the physical world.
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.
When developing software, it’s easy to get forced into dealing with simultaneous problems:
• Scheduling
• Cost
• Features
3 Points of the Dragon’s Triangle
Scope
Resources
Schedule
3 Points of the Dragon’s Triangle
Scope
Resources
Schedule
Software projects 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)
7 8 9 10 11 12
1 2 3 4 5 6
7 8 9
1 2 3 4 5 6
1 2 3 4 5 6
Time Marches At A Constant Rate
Feature Creep
The list of required features always seems to grow longer as a project progresses – never shorter.
The “Sad Truths” Negatively Impact Morale
Dev team sees the size of the project increase, without a corresponding increase in time and resources
Hiring New People Makes Things 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
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.
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.
“Death March Mode”
• Slang for quickly spending ridiculous amounts of resources to force a project to completion
• Caused by the software manager’s failings
Deterministic Problem: Hauling Dirt
• Adding more people gets the job done faster
• But not really: still scaling problems past a certain point
Software Isn’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
Features Can Be Cut To Resolve Cost & Schedule Issues
Cutting Features Hurts Dev Team 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
If You Have To Cut Features…
• Reassure the affected developers that their work is appreciated
• Feature cuts are due to scheduling reasons, not the developers’ skill level or work product
“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
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
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
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
Conclusion: Software is a “Wicked Problem”
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
Lots of software development “myths” have taken on a patina of truth.
Software Development Myths 1. Software is easier to change than hardware
Large-scale projects in the physical world undergo intensive planning before anyone touches a shovel
With software, it’s too easy to think we “see” the solution and start coding immediately, without really understanding the problem.
Example: Y2K
Software Development Myths 1. Software is easier to change than hardware
2. Processes aren’t needed in “maintenance mode”
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.
Without metrics, processes, and clearly defined methods, everyone loses.
Especially our end users.
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
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.
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.
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
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
Pre-war Japanese industry used high-quantity, low-quality production processes
Post-war Japanese industry focused on high quality products at the expense of quantity.
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.
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
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.
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
QA’s job isn’t testing software to find bugs – its job is to prevent bugs in the first place.
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
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
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.
Perks Drive Wrong Kind Of Person Into Management
Managers would rather be coding, don’t deal effectively with HR issues, and are generally miserable.
Pay Should Be Tied to Value, Not Position
Many managers at successful firms are paid less than some of the engineers who work for them.
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
Balance
Don’t abandon your processes, but don’t slavishly follow processes that don’t make sense for your situation.
Good Processes Are Useful In Emergencies
Effective processes have evolved over time to work in both ordinary and extraordinary circumstances.
Example: Out-of-stock Airplane 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.
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
Definite First-To-Market Advantage
First company to offer a product in a new market niche usually grabs 60%-80% share.
Lock Up
Difficult to compete in a saturated market – “rip and replace.”
…But how long does it really take to put together some reasonable processes?
“Land Rush” 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.
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
Commercial Off The Shelf (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?
Intrinsic COTS 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.
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
Avoiding Processes to Avoid Change
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).
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.
Maintaining Schedule Control
Time marches forward no matter what you do.
Too easy to not realize how far behind a software project is until it actually fails.
Godzilla Doesn’t Kill Software Projects
Schedules almost never slip because of a single catastrophic event.
Ducks Kill Software Projects
A single bite from a duck won’t kill you, and a small schedule issue won’t kill a software project.
Actually, LOTS of Ducks Kill Software 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.
Dragon’s Triangle of Software
Scope
Resources
Schedule
Software Management Isn’t An Exact Science
No definite right or wrong answers, processes, or solutions.
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
