
Ask HN: How do you split up the initial work on a complex project? - bigblind
When a project is up and running, it&#x27;s usually quite easy to divide tasks, but I find this harder when getting started. Do you do a lot of whiteboard design, and split it into classes&#x2F;other units of code? How do you make sure these work well together? Or does every project best get started with work by one person, that others can add upon later?
======
MalcolmDiggs
For complex backend projects we usually whiteboard/flowchart as a team first
(high level), and use that diagram to pick which parts should be assigned to
which person.

At that point we start individually writing documentation for our respective
pieces, (as if those services already existed). This might take the form of
Readme files, wikis, or formal API documentation.

Normally the process of writing documentation (and getting feedback on it)
flushes out of a lot of issues. When everything is documented and everyone is
on the same page about what everybody else is doing, then we write our tests
and repeat the same feedback process. Once everyone's tests are on the same
page, then we write our code, and do a code-review when that is done.

Even with all those checks and balances, mistakes and confusions and
miscommunications still happen. But having those regular check-ins to flush
out issues before the real code gets written can save a lot of headache. If
you get to the code review and find an issue, it's probably not going to be a
huge one.

------
staunch
Someone creates the user interface and someone creates each of the backend
APIs that powers it.

Prototyping the user interface can be done by any number of people any number
of times, since the goal is to experiment with different ideas. The backend
APIs are usually mandated by what the user interface requires.

------
ianpurton
To me it's about finding the critical path.

You find what things might stop your project going live and work on those
things first. If they can be worked on in parallel even better.

