A few days ago, a friend was asking me why some of the projects I was participating did not finish immediately, or that I sometimes came back to “tweak” them, so I did an analogy that I will share.
First of all, you have to see a project like a campfire: the more we code the basic structures, the more wood we add to our fire. This is what we call an MVP: minimum viable product; the heart of the idea of the project in which we participate.
The larger the campfire, the more contributors around it
As we tend to add features to our project, the critical mass of this fire cannot spread to infinity without creating a mountain of wood and fire that will not be maintainable in the long run without exhausting all the contributors and burning the forest around (burning the resources of the company).
This is why we have to make small campfires (or features) around to always keep the same number of contributors but in the same place, having cut out the number of operations per small camp of x contributors (say for 10, 2 to 5 contributors, so that FnContributors <= 50% of TotalContributors).
Thus, a feature that is being developed today must be similar to a small campfire near the main camp: it must operate independently, the other small fires do not necessarily need the big one (but can improve it), if a relation between two campfire is necessary, it must never impact the main fire by posing a risk of extinction.
It’s time to go melt some marshmallow now, have fun! 🔥
Top comments (1)
Updated, little clarity about why a little campfire is a feature and why having a huge campfire is not good :)