Ever been on that project where you've been able to turn around a new feature inside an hour? And then the next project where it takes six weeks to turn around a feature that feels just about the same size? You rack your brain, and when you try to figure out why, all you come up with is small stuff. "Well, I guess we have to commit twice for a config change instead of once…"
I posit there are a class of things which are "complexity multipliers"–things which seem small, but when a few of them get together, they have a major impact on the velocity of the project.
The good thing is that complexity multipliers are easy to identify–if you know what you are looking for. They can be things inherent in the structure of the code, in the development process, in the development tools. I'd like to show you some graphs and some common examples and define a conceptual framework of how they affect projects.
8. • 50 Tasks
• Tasks start as an average of 5 days with
about 2 day deviation
• Each task accrues a 1% complexity
multiplier - about 20 minutes on the first
task
A Better Model
Tuesday, August 27, 13
10. • 50 Tasks
• Tasks start as an average of 5 days with
about 2 day deviation
• Each task has a 10% probability of incurring
about 20% complexity (with a deviation of
about 4%)
A “Realistic” Model
Tuesday, August 27, 13
17. “A basic principle of data processing teaches
the folly of trying to maintain independent
files in synchronism. It is far better to
combine them into one file with each record
containing all the information both files held
concerning a given key.”
– Fred Brooks (in 1975)
Tuesday, August 27, 13
18. Stage Gates
• Sign-off required by another team
• Work required by another team
• Any process required for each task (or
group of tasks) to proceed
Tuesday, August 27, 13
20. FuzzyVersion Matching
• Package A: 2 point versions released
• Package B: 3 point versions released
• Package C: 2 point versions released
• Total: 12 configurations
Tuesday, August 27, 13