Chapter 7 in Rapid Development
Every project has one
It encompasses the entire timeline from the concept of version 1.0 to release of documentation for version 12.7a, patch 2f
What steps to follow, and how you know when to move on to the next step
There are many different approaches. There are many hybrids.
The key is picking one that is appropriate
Then, following through
1. Rough idea of project
2. Start coding and reworking
3. Done, eventually
Good Aspects
shows results immediately
good for showing marketing and management
Bad Aspects
shows results immediately
“click-boom” syndrome
Pat Cook’s “Law of Demo failures”
Pro Pilot
Director in office at 9:30
Leaves at 9:40 (nav aid dialog box)
Artist comes in at 4:15 “Here’s your dialog boxes”
What do you mean “plural”?
How late did this project ship?
“Official” step-by-step with sign offs at each stage of progression
1. Software Concept
2. Requirements Analysis
push this button, what happens
3. Architectural Design
what code does what jobs
Data-flow diagrams
in “c”, functional decomposition
in “c++” class organization, responsibilities
4. Detailed Design
class member functions and variables
5. Coding and debugging – the fun stuff
6. System testing
Unit testing
System integration testing
Good Aspects
If staff is new or inexperienced
Bug fix or patch revision
Bad Aspects
One step reveals fault in previous step
Worse Aspects
One step reveals fault in step several back
Bowlervision
What if a lane is shut down when you try to send 10 Pin bowling to it?
D’oh! Didn’t think of that
Based on hope and optimism
1. Think a little
2. Design a little
3. Build a little
4. Test a little
“Risk Based”
Evaluate most difficult aspect, and tackle that first
If appropriate build prototypes to test the riskiest architectural decisions first.
“Proof of concepts”, so:
Learn what worked
Learn what didn’t and had to be kluged
Throw them away
Very tempting (especially to management and marketing) to keep them since they are so close to being done, but don’t
Re-implement a new set of classes with the knowledge gained
Kid Pilot
Think – take existing game and provide a whole new user interface understandable to kids
Design – dialog box centralizing system
Build – pick the most complicated data path and do it first (user sign in)
Test – Make sure it works, especially for boundary conditions (no name, duplicate name)
1. Things Change
Try to anticipate changes in the product at every step & apply mods (testing, docs, requirements, everything)
2. Teams need coordination
Easier if everyone is on the same page
Even if everyone doesn’t agree on style, the process must be maintained
3. Complexity
Can be managed through careful use of discipline.
It can make complexity manageable if you have a plan
For your projects:
Tempting to use “Code & Fix”
For MY sake, try another just for the sheer experience of it
Some day, when you’re in your living room coding in your underwear, it won’t matter. So take the time now.
Look in the book for a discussion of some of the other approaches