- Engineering Complexity
- Birth of Murphy for Java
- People = Problems
- Education Through Pain Management
- The Twenty-Cent Solution
- Fraternal Clones
- "We Lost the Napkin"
- The Devil in Blue Jeans
- Jack and the Beanstalk
- The Slashdot Effect
- The Funhouse Microphone
- That "New Car" Smell
- If I Can See It, It Must Be Wrong
- The Ugly American
- Murphy's Law
- Use Egg Cartons
- Conclusion
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Jack and the Beanstalk
Law: The bigger they are, the harder they fall.
Q: Is the project large?
The larger a project is, the more complex it becomes. The greater the complexity of a project, the greater the odds of failure. Large projects can be segmented into smaller pieces. Smaller pieces are less complex and less prone to failure. By creating many small units of work, it's less likely that the whole system will fail. More importantly, the smaller the step or task, the easier it is to throw it away and restart with an alternative or backup plan.
Human nature doesn't always lend itself to breaking apart large tasks into truly stand-alone units. The best way to succeed with a large project is to iterate and correct the plan as you go, to prove or disprove assumptions about the tasks. The key is to keep iterations small enough that the cost of failure is acceptable. In addition, the odds of failure will be reduced.
Low Risk
The project will take less than a month of effort.
Five or fewer programmers are involved.
The project is large but we use small teams and iterative development.
High Risk
The project will take more than one year of effort.
There are more than five programmers on the project.
Risk Management
Plan large projects with testable units that are about two weeks apart.
Develop only the minimal requirements and then add more functionality over time.
Keep design teams as small as possible.
Present each iteration to the customer for approval.
After each iteration, evaluate the plan and change it if necessary.