Adventures in Product Development

Adventures in Product Development Cory von Wallenstein Dynamic Network Services Inc. May 1, 2009 – ECE 2799

Overview
Relevancy
Before
Team selection
Understand requirements
Leave no question unanswerable
During
Testing
Importance of iteration
Keep it simple
After
Embrace failure
Accept responsibility

Relevancy
Small companies: < 50 folks
Small budgets: ~ $1 million
Fast turnaround: 6 months or less
Corporate culture:
Aspire to be the best.
Never be outworked.
Welcome failure.

Team Selection
No greater project impact.
No greater return on investment.
Individual differences:
Count on the best people outperforming the worst by about 10:1.
Count on the best performer being about 2.5 times better than the median performer.
Count on the half better-than-median performers outdoing the other half by more than 2:1.
Source: Peopleware: Productive Projects and Teams ; Demarco, Lister

Understand Requirements
Alleviate pain, receive compensation.
Talk to your customers.
What are they paying for now?
Why should they pay you?
Listen.
Focus on a niche. Be the best in that niche.
Polarize.

Discover problems when they are cheap to fix.
Leave No Question Unanswerable Source: Code Complete; McConnell Time Introduced Time Detected Requirements Architecture Construction System Test Post Release Requirements 1 3 5 - 10 10 10 - 100 Architecture - 1 10 15 25 - 100 Construction - - 1 10 10 - 25

Leave No Question Unanswerable
How does… ?
When should… ?
What happens if… ?

Testing: Invert the Goal
Typical Goal:
Build a widget that measures light intensity.
Inverted Goal:
Build a widget tester that generates light of varying intensity, and can connect to a widget to verify the measured value of intensity. Oh, and along the way, we’ll have built a widget that measures light intensity.
Shocking fact: Roughly the same cost.

Time typically used for:
“ It was working yesterday…”
All-nighter debug sessions.
“ When I touch this wire, it works…”
“ It worked on batteries…”
“ WTF?!?! Why isn’t it working?”
“ We’re 95% complete.”
Real world:
“ You know, everything would be fine if the stupid customers would stop breaking it.”

Time is now used for:
Iteratively building a repeatable test suite and test harness.
Provides confidence that what you built yesterday, still works today.
Easy progress indicator… if there’s a passing test for it, it’s complete.

Iterate, Don’t Waterfall
Waterfall model – Six week duration:
Weeks 1 and 2 – Spec out requirements for features A, B, C and D
Weeks 3 and 4 – Build features A, B, C and D
Weeks 5 and 6 – Testing and quality assurance for features A, B, C and D

Waterfall model – Nine week duration:
Weeks 1 and 2 – Spec out requirements for features A, B, C and D
Weeks 3 and 4 – Build features A, B, C and D
Weeks 5 and 6 – Testing and quality assurance for features A, B, C and D
Weeks 7 and 8 – Fix bugs found in features B and C. Feature D only works when not used with feature A.
Week 9 – Fixes break feature A. Fix feature A. Test.

Iterative model – Six week duration:
Weeks 1 and 2 – Spec out feature A. Build feature A. Work with Q & A to test feature A.
Weeks 3 and 4 – Spec out feature B. Build feature B. Work with Q & A to test features A and B.
Weeks 5 and 6 – Spec out feature C. Build feature C. Work with Q & A to test features A, B and C.
Deliverable product, albeit missing feature D, but it was low priority anyway.

Simple as Possible, But No Simpler
Simpler products get built sooner.
Put into customers’ hands more quickly.
Feedback arrives earlier.
Market traction takes hold.
Use feedback to decide new priorities.

Embrace Failure
Failure is an opportunity to learn from your mistakes.
Regrets turn into lessons.
Failure is different from negligence.

Accept Responsibility
The only way to improve is to accept responsibility for what needs improvement.
Point criticism inward, before you point it outward.
More constructive, since it gives you something you can actually control.
“ I’m sorry. I messed up. I’ll fix it.”

Summary
Before
Team selection – Greatest indicator of success.
Understand requirements – Build the right thing.
Leave no question unanswerable – Save time and money.
During
Testing – It sure beats debugging.
Iterative development – You will be happier. Trust me.
Keep it simple – You can always add it in later.
After
Embrace failure – It’s an opportunity to improve.
Accept responsibility – Actionable criticism is good.

Adventures in Product Development

by Dyn on May 01, 2009

Accessibility

Categories

Tags

Upload Details

Usage Rights

2 Embeds 30

Statistics

Adventures in Product Development — Presentation Transcript

http://www.standingonthebrink.com	29
http://localhost	1