How to decompose: the exciting part
Here I want to focus only on decomposition, without any attention to estimation.
Same I recommend to do with day-to-day stuff: the first divide, then count.
I will write a separate article about estimation later, don't worry.
"How to eat an elephant: a bite at a time" is so easy to say and hard to achieve.
I could say the same about this article, which is quite challenging for me to write.
It is not my first attempt, and the catch I am trapping in is that the text becomes misbalanced all the time: either too theoretical or too practical and specific.
Funny because the balance is probably the main issue with decomposing. You want to see a complete picture, but usually, it is too vague or unnecessarily detailed.
Another issue is that the process is exhausting: you need to put a massive effort into it, and there is no guarantee that the result would be even close to what has been planned.
I am sure you've been there when the plan was A, and eventually, it wasn't Ai or even B, but a fucking foreign alphabet letter because Latin is not enough.
Our goals
They looks pretty simple:
Cut an 'elephant' into pieces.
Ensure that they aren't too large or tiny.
Make it relatively easy, so the team has the energy to eat those pieces.
One more goal is important: each element either has a dependency (we need to do another element before we can start doing this), or it is a dependency (while we are doing it, everything else is blocked).
And we want to decompose in a manner when we would have as many independent tracks as possible.
Why? This approach has many advantages; the obvious is that you can put more engineers into the feature, and it will (actually) bring value instead of the mess. Another is that it (keep reading) helps you create a better design.
The credit for this brilliant idea goes to my friend Leo 👋🏻!
Practical part
Let's say for our SuperCompany's Chat, which is targeted for uniting families, we need to plan a significant feature: fridge door!
The fridge door is a separate screen with, well... 'fridge door'-like design and the ability to put a sticker on it. Stickers could have a target: a person from a family, or they could be general. They also work as reminders, so they have a date and notifications integration. Any message could be converted into a sticker.
Examples:
'Hey, @dave, don't forget to take Luna to the vet | For tomorrow at 2 p.m.'
'Family, about Gram's 90th birthday in March, we want to make it huge, fund it here: [link]!'
Of course, this input is poor, but it is good enough for demonstration purposes.
First take
Here are a few ways to decompose some parts (not the whole!) of this feature.
The first attempt is simple:
— we need to create a 'door,' which would be a Drag&Drop area for some cards (stickers);
— then, we need to wire it to the backend;
— and if we're lucky, we will have time for an extra feature.
In this scenario, we have two parallel tracks that depend on the first huge part, which is the most important and will likely take more than half of the project time.
Second look
Let's try to make it more parallel and a bit more specific.
You might say that your team is small and two tracks are good enough, but that would be a trap you need to avoid.
Make as many tracks as possible, even when you don't have enough people to work on each track: it gives you flexibility (for example, if one of the tracks is blocked by an external team), it results in a better design.
We defined an abstract area (it probably will have some initialization interface) that will work with some cards (stickers) and store coordinates per each.
This structure unblocks other features and other tiny things that we can do in parallel: create mocked backed client, which we will use later in tests, but for now, it is enough to unblock the main track completely.
So this decomposing game is an iterative process of thinking over modules and abstractions you have to build to implement the feature.
However not that simple from a big piece to smaller parts, but for each iteration, you need to aim to make as much unblocked tracks as possible.
Final touches
Next, let's talk about actual pieces. How finely should we split?
Opinions differ; some say that until we get tasks that we could estimate in hours, or not more than a day, or the iteration (week or two).
Common sense tells me that I should split until it splits.
I don't want to see too detailed squares, like: 'write a function which concatenates two strings,' as well as too general, like 'draw a fucking owl.'
If I urge to add comment and square isn't self-explanatory, I would split it into few.
Let's back to our first version.
The 'Drag&Drop Area module' is too vague. As an engineer, I would prefer to put some clarifications there, like:
we need to have an area (canvas or just a regular HTML container?) that can store items with coordinates;
we need to have a Drag&Drop feature, so each item will produce an event during the drag process and on drop event that we will use for the persisting the state: there might be some libs for that, we need to do research;
we need the persisting interface to call (mocked in tests and the real one);
considering the area size and notes sizes, we need to write a function that can arrange notes one by one.
Okay, let's put it on the board.
As you can see here, we added a few research squares, which might make the dependency between the fridge door (area) track and the cards (stickers) tracks less tight (red arrow highlights it).
Maybe if we choose libs and approaches wisely, it will unblock us. And maybe with an excellent existing library, the whole 'cards' track would be super simple; and it might be converted later, after the research is done, to just a square that says: 'Integrate with Super-Duper D&D library.'
I want to emphasize again that these images are just a part of 'Fridge' feature decomposition; we didn't touch Stickers, internal integrations with notifications (reminders), mentions and creating Stickers from a message, etc...
The next important thing I want to talk is the third item in our goals list above.
It is about how exactly to organize the decomposition process and routines, and I wrote a separate post on the topic