"No, it's less effort than that"

My estimate math:

R = t × [1.1^ln(n+p) + 1.3^X]

R - time it really takes.

t - shortest possible time it would take without need to communicate.

n - number of people working and involved during the process, both customers and developing organization.

p - longest communication distance network involved in the project (typically from the lowest level developer to the end user)

X - number of new tools, libraries, techniques, used in the process.

Example. Project involving one developing writing code. Project would take 2 weeks (t=2), but it has 5 people (n=5) involved total, only 1 new tool (X=1) and longest communication distance is 4.

2×(1.1^ln(5+4) + 1.3^1) = 4.5 weeks.

Out of curiosity, how did you came out with this formula? What’s the math behind it?

It’s from his butt. Which makes it just as valid as how everyone else does estimates.

>X - number of new tools, libraries, techniques, used in the process

How would you know this before starting dev work?

Crude estimate based on some self evident truths:

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.

new to the team, I suppose. Everyone on the team has shipped a rails heroku PG app? Then you have a low number of shinies.

Shipping a Vaticle + Haskell on nixOS in your own server farm?

Maybe that's more new tools for the team...

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.

Why does zero new tools (X) add time?

Alternatively, why does one new tool add so little time?

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.