Ok, how do i usually respond to question like "if i add 1 more engineers to your team, can it be done 1 week instead of 2 weeks?" You should explain that projects will involves multiple stages, planning, development, testing, launch / monitoring, optionally... patch iterations so not all stages can benefit from more people, in fact it can slow it down due to communication overhead On top of that, never ever treat your estimations as promise / deadline, most of time people under estimated the actual development time
Brooks's Law states that adding more engineers to a late software project can make it take longer, not faster, because of increased communication overhead, a need for training and onboarding, and the inherent difficulty of dividing tasks in software development
I agree that not all stages would benefit from more people, but keep in mind that in development phase, more often than not more people actually CAN mean more speed
My oven can’t go above 450. What your point?
There is a reason the saying goes "Too many cooks in the kitchen." In addition, mathematically it may make sense that adding one person should shave off 1 week, but the truth is it takes 2 weeks to onboard that person, 4 weeks to train them on the software at the level the team is at, several other people are pulled from their tasks to help out the new person. What should be faster actually makes EVERYONE slower.
What if I add another oven? 😆
Warren Buffett said "you cant expect 9 women to deliver a baby in 1 month" or something along that line, seems also applicable in software engineering
Indeed, brute forcing never works and doesn't deal with cognitive complexity and work synchronisation
Maybe the question shouldn’t be - will more people help - it should be can the work be split into parallel streams that have little dependencies? If that answer is yes - then the next question should be - could we add more people to cover the additional streams?
This is a common issue almost every IT company faces. Instead of arguing about how many devs and timelines are needed. I think there is a crucial substantial main issue behind, it is about priority management. We should put many things into consideration before we start the project, so as we truly understand what the project is all about, we can do things with keeping priorities in mind, all the teams top to bottom must be aligned with the same perception. Perfection needs a barrier corridor to make it real, concrete and measurable. What's the point(?) Sometimes our own obstacle is trying to be perfect without any (realistic) base.
Product Designer
1wLove the image reference 😆