1975: Fred Brook's wrote[1]:
“The bearing of a child takes nine months, no matter how many women are assigned.”
Can't get better than this
"No, it's less effort than that"
21–30 of 388 posts
Re: "No, it's less effort than that"
#22If you're asking for estimates from devs at all you're probably pushing waterfall on them. If you want to be waterfall, that's fine. If you're forced into doing it by your business context, that's also fine. But, you shouldn't be under any illusions about what you're doing. It's a waterfall behavior that will drive waterfall effects.
That's just not true. It _can_ be waterfall, but story points are everywhere in agile development.
Story points are for relative sizing are not estimates. That's why you use story points and not hours or days. They're for re-arranging the priority of stories and deciding which ones to do or not.
Re: "No, it's less effort than that"
#23The only magic wand in software development is to simplify requirements. The requirements are always wrong: too broad, too vague, based on invalid assumptions
The real genius is to propose a simplified solution, by discarding some assumptions. This is the best and only way to shrink the schedule
Re: "No, it's less effort than that"
#24My 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, techniq…
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.
Re: "No, it's less effort than that"
#25Unlike the meteorologist, the developer has the ability to bend reality a bit when it comes to estimates, but they can never bend reality in a way which makes it worthwhile. Cutting corners is almost always a mistake. It's a very short term move which may only make sense if the business is collapsing and looking for a quick exit.
Re: "No, it's less effort than that"
#26This is a bad metaphor. You can't make the sun come out faster by dropping features.
What you can do is release a product faster with less features and continue working on adding the missing features after the initial release.
This happens all the time in embedded systems which can be updated by the customer.
Re: "No, it's less effort than that"
#27My 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, techniq…
>X - number of new tools, libraries, techniques, used in the process
How would you know this before starting dev work?
Re: "No, it's less effort than that"
#28A valuable discussion to have is about how to change the scope so that the cost/return tradeoff is right for your stakeholders. I've definitely seen devs assume too much needs to be done, just like I've seen non-devs ignore key parts of the problem that push up the time. Sometimes it's trying to make a general solution when actually what's needed is someone to sit down with a spreadsheet for a day. > There is back-an…
>but this is the issue addressed with planning poker.
It isn't. Having a team which is both intimately familiar enough with the set of features as a whole, and understands how to use the system to get around the inevitable 'A does it in X while B does it in X*3', are both prerequisites. Suffice to say, with the amount of discussion based around Scrum being done wrong alone, neither of those are even remotely a given. This also doesn't take into account turnover and new features being able to remove a team from meeting those prerequisites at any point.
Too often it just devolves into people raising eyebrows at one another and either it becomes 'X will do it, so X's estimate becomes the value' (why even bother doing poker then) or 'take the average or minimum' which screws over anyone who estimated higher.
Re: "No, it's less effort than that"
#29My 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, techniq…
Out of curiosity, how did you came out with this formula? What’s the math behind it?
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.
Re: "No, it's less effort than that"
#30Management has to push for lower estimates because developers have an incentive to overestimate to make life easier. The only situation where this isn't a problem is with eager junior devs, and devs that have direct skin in the game, such as at startups or a department about to be cut for being unprofitable.
> Management has to push for lower estimates because developers have an incentive to overestimate to make life easier.
Developers have to push for higher estimates because management has an incentive to underestimate to make life easier.
See what I did there? There's a fallacy in both statements: one side's actions are portrayed as greedy pursuit of "incentives" while the other side's actions are portrayed as a natural and logical counter to those incentives.