“In XP, we don’t divide and conquer. We conquer and divide. First we make something that works, then we bust that up and and solve the little parts.”
Kent Beck
An approach to dealing with a large problem might be to break it up into smaller pieces and use separate teams to solve each piece before finally integrating the overall solution at the end. In other words, divide and conquer.
The typical result is what is known as “integration hell”.
Instead, the Extreme Programming community advocated what was called “conquer and divide”. That is, starting with a single, cross-functional team to solve a holistic subset of the overall problem in order to work out the essence of the components and interfaces, and only after that, scaling up. In other words, conquer the problem before dividing into multiple teams (and exposing yourself to integration risk).
Many other practices in the Extreme Programming and Agile software development community reflect this principle of “conquer and divide”, that is, conquer the core of a problem first before addressing the entire problem in the large:
- A spike solution is a technical prototype that drives a spike through all the components / layers of the proposed solution first before scaling up.
- A walking skeleton is a spike solution used to validate the overall architecture before scaling up.
- Minimum viable products are the smallest set of experiments that validate the essence of your business model / product assumptions before scaling up.
- A project inception is about building collective agreement on the direction and approach for an initiative before scaling up.
I suspect there is an underlying difference in beliefs that leads one to tend toward divide and conquer versus conquer and divide.
If you believe not having enough people is your main constraint, you will tend to divide and conquer; if you believe integration problems are your main constraint, you will tend to conquer and divide.
