Divide and conquer
Managing Overwhelming Projects is about breaking a big project into small enough pieces for one person to hold in their head. This resource is about the next question: once you've broken it down, how do you actually split that work across a team of four or five people without everyone stepping on each other constantly?
The core idea
"Divide and conquer" as a team strategy means splitting work along boundaries where each person or pair can work independently, with minimal need to coordinate moment-to-moment. The goal isn't just splitting tasks — it's splitting them along lines that don't create constant collisions, blocking, or merge conflicts.
Why is this important?
Badly divided work is often worse than not dividing it at all. Two people editing the same file all week, one person permanently blocked waiting on another's unfinished piece, or three people quietly rebuilding the same component in slightly different ways — these are extremely common in student teams and they erase most of the benefit of having a team in the first place. Good division of labour is what actually lets four people move faster than one, rather than just producing four times the confusion.
Good ways to slice a project
- By layer — frontend vs. backend vs. database, for example. Works well when the interface between layers (the API contract) is agreed early and doesn't change often.
- By feature — one person owns "enrolment," another owns "authentication," another owns "admin reporting." Often causes fewer collisions than splitting by layer, since each person can work top-to-bottom on their own feature without waiting on someone else's layer.
- By pipeline stage — one person designs, another builds, another tests. Works for creative or design-heavy projects, but can create bottlenecks if one stage takes longer than expected and blocks the next.
For most student software projects, splitting by feature tends to cause the least friction, because it minimises how often two people need to touch the same code at the same time.
Watch out for hidden dependencies
The whole strategy falls apart if the pieces secretly depend on each other in ways nobody planned for. Before splitting work, explicitly ask: what does each piece need from the others, and in what order? If the enrolment feature needs the authentication feature finished first, that's not a reason to abandon dividing the work — it's a reason to agree the shared interface (what data gets passed between them) up front, so both people can build against that agreement in parallel rather than waiting on each other.
This is where a small amount of upfront design (see Design Thinking and Requirement Analysis) pays for itself: agreeing on interfaces and data shapes before splitting the work is far cheaper than discovering the mismatch after two people have each built half of an incompatible whole.
Recombining the pieces
Divide and conquer isn't finished the moment work is split up — it's finished when the pieces are successfully put back together. Plan integration points into your schedule explicitly (don't leave "merge everything" as an unplanned afterthought in the final week), and integrate early and often rather than only once at the very end. A feature that "works" in isolation but has never actually been tested alongside the rest of the system is a common and entirely avoidable source of late-project panic.
Tips
- Write down the interface/contract between pieces before splitting the work, even informally — a shared doc listing what each part sends and expects to receive is usually enough.
- Integrate continuously (daily or every few days) rather than saving it all for the end. Small, frequent integration surfaces mismatches while they're still cheap to fix.
- Give each independent piece a clear, single owner. Shared, un-owned pieces of work tend to quietly not get done, because everyone assumes someone else is handling it.
- Revisit the split partway through. Some divisions look clean on a whiteboard and turn out to be tangled in practice — that's fine, just re-divide rather than forcing the original plan.
References
Sethi, R. Software Engineering: Basic Principles and Best Practices — covers modular decomposition and interface design as a foundation for splitting work across a team.