1. 10
  1.  

  2. 4

    I like estimating things, so I guess the author probably wants to talk to me. But I don’t think there is anything surprising here.

    I think there are several benefits to estimation, depending on the circumstance:

    • At $work, when things are going According To Plan, we try to write straw man implementation paths for any non-trivial ticket. At our planning meeting (~2 hours every 2 weeks), we each discuss our tickets and implementation plans in enough detail that (most) others can understand. We are all asked to roughly estimate the amount of work (in “ideal days”) required to take the proposed implementation path. The specific number we come up with provides a ballpark, and in particular, consensus gives some confidence to that number, but it also helps provide confidence that everyone is on the same page. Once in a while, we will have a huge disparity in estimates (we all estimate at the same time), and that almost always leads to really useful clarifications on the task at hand.
    • On my own time, I often do implicit estimation as a way to determine what I work on next. If I know a task will take only a few minutes, then I try to put those into a queue, and when that queue gets big enough, I drain it in one swoop. I try, anyway. If I estimate a task to take several days and another to take several months, then that will also influence how and when I work on those things, and in particular, the ordering of tasks.
    • Estimation is also a form of managing risk. The specific number that comes from the process isn’t so important as the process itself. In order to produce a good estimate, you need to work through the implementation plan in enough detail that you can actually see through the entire task. (Or, at least, you perceive to. Doing the implementation itself will frequently raise new concerns, but remember, I’m not claiming estimation to be a panacea. I’m claiming that it is a form of risk management.) It’s the journey friends, not the destination.

    I think the OP actually mentioned several of the things I said above, and is seemingly already convinced it’s bullshit. So… I guess my experience is wrong then? ¯\_(ツ)_/¯ In any case, I am at a tiny startup, not a giant corp, so that could make all the difference.

    1. 3

      Great topic. Dan Milstein’s take on this same problem and solution is another in-depth exploration of these ideas.

      1. 2

        In my experience doing web dev I have seen mostly people want to know how long something will take to see if it’s worth doing for example “Hey I had this idea how long will that take?” “About 20 hours” “Ok no don’t worry about that then” If you don’t tell them around about how much something will cost you end up with this problem https://xkcd.com/1425/ and the customer gets pissed that something they thought would take an hour has taken all week.

        1. -2

          Here’s my issue: if you’re asking me for an estimate, you’re communicating that what I’m doing isn’t that important. If it were important, you’d get out of my way. A deadline is a resource limit; you’re saying, “This isn’t important enough to merit X, but if you can do it with <X, I guess you can go ahead”. If you ask me for an estimate, I have to guess your X (and slip under it if I want to continue the project, or exceed it if I want to do something else). If that seems self-serving or even dishonest, well let’s be honest about the dishonesty, at least here: estimates are bullshit anyway, so why not use the nonsense game for personal edge? Of course, if you’re the one being asked for an estimate, the system and odds are against you in nearly all ways, and you probably made some career-planning mistakes if you’re my age and still have to give estimates, but never mind that for now….

          There are projects that are nice-to-have but not important and might be worth doing, but that aren’t worth very much and therefore should be given resource/time limits from on high. I just don’t want to work on those. If it’s not doing with an open deadline, then assign someone at a lower skill level, who can still learn something from low-grade work. This isn’t me being a prima donna; this is me being realistic and thinking about job security. If having it done cheaply is more important than having it done well, I can (and should be) replaced by someone else.

          1. 3

            Businesses regularly put resource limits on investments, I don’t see why software engineering salaries are exempt from this.

            1. 0

              I don’t see why software engineering salaries are exempt from this.

              It might have something to do with the fact that the top 5% of us, at least, are smart enough that we ought to be calling the shots, rather than being pawns on someone else’s board.

              1. 2

                Unless you are literally on the board of a privately held company, you are pawns on someone else’s board. This isn’t hopeless, it’s just being honest with where actual final financial votes are cast.

                How “smart” you are doesn’t mean you deserve to call any shots, as much as anyone who owns the company doesn’t deserve to either. Building relationships, managing expectations, cost analysis and collecting requirements are all part of making engineering estimates, and they are tools for you to exert influence over someone who has ownership/authority.

            2. 2

              What if all work is estimated? These inferences depend on selective estimation.

              1. 1

                I’ll disagree with you here a bit–I agree with your last paragraph’s approach, but I think you are leaving out a little bit.

                It’s worth it to send overqualified engineers into certain projects exactly because they are more likely to know how to fix problems preemptively and because they are more likely to have a narrower distribution on the time taken to achieve the task. If you want something with a known problemspace done correctly and to a guaranteed standard and in a timely fashion, you shouldn’t send people who are still learning.

                “This isn’t important enough to merit X, but if you can do it with <X, I guess you can go ahead”.

                Unfortunately, this is a lot of business, right? Like, scheduling and organizing coverage and resources for projects often means that, say, a full rewrite would take too many engineers off of customer-facing work, but incremental cleanups are possible.

                From the employee side, it is arbitrary, but there is at least a chance of method to the madness.