1. 14
  1. 5

    I’m not sure “I refuse to do my job until you do yours” is actually the best way to build good will.

    1. 2

      I haven’t given hours for probably a decade. Since then I’ve been at companies where, as a team, we only need to provide story estimation points in a Fibonacci range. I think this is pretty normal practice for development teams following the agile/scrum methods.

      I suppose internally this is all converted to hours by managers looking at the team’s velocity although I’m not sure and thankfully I never have to worry about it.

      1. 8

        Man, everyone uses fibonacci numbers for estimation but it seems really weird to me – in practice it just means anything but 4.

        1. 3

          Most software developers are too lazy to actually learn how to estimate what they’re doing. Everybody else in every other field (new or old) is perfectly capable of estimating how long work will take, what it will cost, and how much they’ll get done each week. But software developers apparently can’t, or more realistically, they refuse to do so. I don’t know why software developers think they’re super special, but they do.

          They can’t be bothered, so they invent ever more fanciful ways of refusing to give proper estimates. The current trend is that they’ll give it in ‘story points’ in some pseudo-mathematical scale that sounds fancy (Fibonacci numbers) but is in fact completely meaningless in the context of estimates, and then claim that you can’t do arithmetic on them.

          Reality is of course that people hate being measured. And because people think software developers are all very smart, they trust developers when they say things like ‘you can’t add these estimates to get the amount of work you should expect me to do each week then hold me to it’. Of course they can. They’re time estimates. If they weren’t estimating how long things took they’d be completely and utterly useless and nobody would bother doing them in the first place.

          I don’t really know what software developers expect. ‘Assign me a task and I’ll let you know when it’s done’. ‘Roughly when will that be?’ ‘You can’t estimate software development timelines’. Except you obviously can. Nobody expects estimates to be exact, but they shouldn’t be that hard. Everyone else in the world is capable of estimating how long things take.

          1. 2

            I think the issue is that “You can’t estimate software,” has been repeated so many times that people take it as a truism. Kind of like, “Premature optimization is the root of all evil” and all the pain that has caused. Yes, estimating software is hard, to a point – large scale projects with many team members are hard to estimate in the same way that it is in other engineering disciplines. But if the work item is adding a column to your crappy web app’s database? Not so much.

          2. 1

            My team’s been using Fibonacci estimates but I don’t really think it makes much sense, though in practice it somehow works. For example four 2-point stories rarely take as long as one 8-point story. So what’s the point in measuring the total points that a team accomplishes at the end of one sprint? Maybe our estimate errors add up in a way that cancels the noise.

            1. 2

              They’re T-shirt sizes (large, medium, small) that you can do arithmetic on. I’m not aware of a better justification than that. (Though if you ask me, being able to do arithmetic on your estimates is a serious downside…)