Divide and Conquer
Divide and Conquer
The most popular way to tackle complex projects is to divide and conquer them, breaking big problems into sets of smaller ones whose solutions can be composed. It’s easy for this strategy to go off the rails, though. Here are a few common issues to watch out for.
Scope creep. A task starts off simply enough, but the requirements become a moving target. People decide to add just one more thing… or maybe two or three. Solution: Define completion criteria for each task, and stick to them; or cancel the task entirely if it’s no longer useful. Defer additional work to separately scheduled tasks.
A complex system designed from scratch never works and can’t be made to work. You have to start over, beginning with a simple working system.
—John Gall, Systemantics
Overoptimism. At some point, you’ll need to define leaf nodes in the dependency graph of partial solutions. It’s tempting to think you’ve defined the simplest possible task, only for that task to become a quagmire of unforeseen complexity. You cannot know, before having truly completed a task, what challenges it entails. Solution: Err on the side of defining tasks that are too simple. Set a tone of iterative improvement.
It is faster to make a four-inch mirror then a six-inch mirror than to make a six-inch mirror.
—Thompson's Rule for First-Time Telescope Makers, via Programming Pearls
Lack of shared vision. Especially when many people are working on a project, it’s important to keep all eyes on the same prize. Otherwise, their work diverges. It’s not enough to solve the heck out of all the parts of a complex problem: You must also combine those solutions into a cohesive whole. Solution: Get a shared system up and running ASAP, and define task deliverables as deltas to that system. Do not think the system is useless merely because it doesn’t do much: Its simplicity is its strength. Every ladder needs a lowest rung.
The amazing thing about a dancing bear is not that it dances well, but that it dances at all.
—Anonymous
Aside from the technical success of a project, keep in mind the well-being of your team. Achieving goals, no matter how small, builds confidence, and helps folks learn incrementally. Well-defined, simple tasks that iteratively improve a shared system set your project and your team up for success.
The morale effects are startling. Enthusiasm jumps when there is a running system, even a simple one. Efforts redouble when the first picture from a new graphics software system appears on the screen, even if it is only a rectangle. One always has, at every stage in the process, a working system. I find that teams can grow much more complex entities in four months than they can build.
—Fred Brooks, No Silver Bullet