[wpietri]

I have had many successful projects where we spent approximately zero time on estimates. The fact that a successful approach is culturally seen as illegitimate to even talk about is a great example of why I wrote that last paragraph.

[awesome_dude]

Whenever there are constraints (money, time, resources) there are going to be estimates and prioritisation.

You might be speaking a little more broadly than I am interpreting.

[wpietri]

On the contrary, constraints often mean you don't need formal estimates. (I'll come back to prioritization in a sec.)

Startups are a great example. When you raise your first chunk of money, the size of that isn't really driven by a carefully considered, detailed plan with engineering hours estimated per task. What you get is basically determined what's currently fashionable among angels and small-end VCs, plus who's doing your fundraising. (If you're Jeffery Katzenberg and Meg Whitman, you can raise $1bn. [1] https://en.wikipedia.org/wiki/Quibi But the rest of us have to make do with what we can get.)

So at that point you have a strong constraint (whatever you raised) and some relatively clear goal. As I said, cost isn't nearly as relevant as ROI, and nobody can put real numbers on the R in a startup. At that point you have two choices.

One is just to build to whatever the CEO (or some set of HiPPOs wants). Then you launch and find out whether or not you're fucked. The other is to take something akin to the Lean Startup approach, where you iteratively chase your goal, testing product and marketing hypotheses by shipping early and often.

In that later context, are people making intuitive ROI judgments? Absolutely. Every thing you try has people doing what you could casually call estimating. But does that require an estimation practice, where engineers carefully examine the work and produce numbers? Not at all. Again, I've done it many times. Especially in a startup context, the effort required for estimation is much better put into maximizing learning per unit of spending.

And how do you do that? Relentless prioritization. I was once part of a team that was so good at it that they launched with no login system. Initial users just typed their names in text fields. They wanted proper auth, and eventually they built it, but for demonstrating traction and raising money there were higher priorities. It worked out for them; they built up to have millions of users and were eventually acquired for tens of millions. On very little investor money.

Being great at prioritization makes estimation way less necessary. The units of work get small enough that the law of large numbers is on your side. And the amount of learning gained from the things released change both the R and I numbers frequently enough that formal estimates don't have a long shelf life.

So I get what you're saying in theory, but I'm telling you in practice it's different.

[1] https://en.wikipedia.org/wiki/Quibi

[awesome_dude]

Wait, your first example is "We raised X dollars" which is a literal estimate of the worth of the company?

I think you are well missing the point - everything you put into your rebuttal is about estimates - in time, money, or resources

[wpietri]

If you're saying there's some sort of wisps-and-moonbeams notion of estimation in everything that we do, sure. I'm not going to argue with that. One world, brah.

What I am talking about here, though, is a practice of software estimation where programmers produce detailed numbers on the amount of time requested work will take. Which is certainly the common meaning of estimating around here, and also what the original article is about.

[awesome_dude]

"Brah"

I mean, if this is upsetting you, take a minute and go for a walk.

> You might be speaking a little more broadly than I am interpreting.

(Or I could be interpreting it more broadly)

In either case I don't think your response is apt

[wpietri]

I'm not upset. But as far as I can tell you've wandered off into some sort of philosophical space when I'm speaking of practicalities, without apparent recognition of the transition. I thought that was a bit ridiculous, something from the "wow dude have you ever really looked at your hand" school of conversation, so I made a joke. Apparently the joke didn't land for you. Alas.

[lmm]

Research is subject to constraints of money, time, and resources, but is not normally estimated in the sense that software industry people would use the term.

[bpt3]

Yes, yet estimates are still made. The author of the article didn't use some highly formal definition of estimation, didn't imply one, and seems to be focused on devops (not software development) as a practitioner.

Estimates are difficult, and in unhealthy environments are weaponized against developers. That doesn't mean they're unnecessary or impossible.

[awesome_dude]

I think that the replies I am getting are demonstrating why developers have estimates used against them - people forget that they are estimates, and they also forget that when new information comes to hand that invalidates that estimate a completely new one may need to be created to take into account the new data.

If developers (or anyone giving estimates) discovers that the initial estimate was based on faulty information then they need to push that information back to whomever they are reporting it to (Team Lead, Product Owner, Manager, customer, angel investor...). The receiver of that information then needs to decide on how to react according to the changes.

[bpt3]

Yes, agile is a reaction to spreadsheet driven development and some very dumb ways of tracking progress towards completion and managing work in general.

In my experience, people don't forget they're estimates, they just want to force developers to meet whatever they agreed to that's most convenient for management.

If you want to fight back against that, my experience has been that giving terrible estimates or refusing to give them at all will not result in more autonomy or authority.

[lmm]

> If you want to fight back against that, my experience has been that giving terrible estimates or refusing to give them at all will not result in more autonomy or authority.

In my experience giving terrible estimates or refusing to give them at all is the least bad course of action. It wastes less of your time than any realistic alternative, it does no noticeable damage to the business or your own position, and the people who want to paint you as just trying to avoid accountability were going to find a way to do that anyway.

[awesome_dude]

Research is estimated, sometimes those estimates are hilariously bad (Computer vision is easy, a summer research for a student should be enough), but more often than not it's "We expect that this research will take someone doing a Ph.D approximately 3 - 5 years to do"

The entire premise of a project is "Look at this, with the intent to find X, and, if it's not possible, break it down so that we can create more projects to work toward that goal" which is an estimate, or a breakdown into sub projects that also come with estimates.