On Tuesday, August 27th at noon, I will be presening on "Complexity Multipliers" at the Chicago Geekfest (located at the 600 West office of Groupon).
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.