It's a bullshit formula that can be used to justify "padding" to people that think software development (or any kind of work) is like digging a ditch or like an assembly line.
In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new <whatever's> being used."
It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.
Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow.
New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
From the other angle, you can see how velocity is impacted by using "boring tech", keeping teams small (two pizza team), clearly identifying stakeholder roles, creating efficient communication channels. It's a pretty useful model.
dsomers|2 years ago
crispyambulance|2 years ago
In real world projects you don't actually know "t", nor do you know how "p" and "n" are conditioned by other factors, nor is there any basis (IMHO) in reality to that "1.3" factor in front of "number of new <whatever's> being used."
It's a pity that in so many orgs people can't just be adults, trust each other, and recognize that work often takes unexpected turns.
nabla9|2 years ago
Logarithms for number of people and communication chain come from network theory because network size and network distances slow down information flow.
New technologies bring in unexpected delays and problems that rapidly accumulate in nonlinear ways. If bring in 20 people to work with new programming language, new library stack, etc. everything slows down to crawl.
8organicbits|2 years ago