3 ms·

I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experienc

I think general problem on HN is that you can't say something "bold" without people going "nuts" - especially when it comes to estimating work. In my experience (been hacking since the '90's before it was cool) great developers are great at estimating things. And these are not outliers, all except 1 great developer I've had pleasure of working with over these years has never been "off" on estimates by any statistically significant margin. but you say anything like that here on HN and it is heresy. My general opinion is that developers LOVE making everyone believe that software development is somehow "special" from many other "industries" for the lack of a better word and that we simply cannot give you accurate estimates that you can use to make "deadlines" (or better said project plans). and yet most developers (including ones raising hell here and downvoting any comment contrary to "popular belief") are basically doing sht that's been done million times before, CRUD here, form there, notification there, event there etc... It is not like we are all going "oh sht, I wonder how long it'll take to create a sign-up form." I think we have (so far) been successful at running this "scam" whereby "we just can't accurately estimate it" because of course it is super advantageous to us. and WFH has made this even worse in my opinion - given that we can't provide "accurate estimates" now we can simply pad them (who dare to question this, it is just an estimate, right? can't hold me to the estimate...) and then chill with our wifes and dogs when sh*t is done 6 weeks earlier :)

mewpmewp2 2y ago
It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.
- bdangubic 2y ago
  In your 2nd example of a large corp I can see myself joining and not knowing anything about all these potential landmines etc… but if I was at that corp for say 2-3 years those would all be known things, no? And hence estimates can come with number of assumptions based on 6 other teams doing whatever it is that they need to do etc…? But I totally agree with your point and would not be disappointed if someone missed an estimate in that sort of chaos. My comment was not really geared towards chaotic organizations but general sense (especially in myriad threads on this forum) that SWEs think that somehow our profession is so “special” that we cannot possible know how long something will take. I simply do not accept that and personally believe that more likely vast majority of SWEs simply suck at their job. there are roughly 4.5 million of us, how many are really good at their jobs (big part of which is estimation)? probably like 0.4% :)
  - WOTERMEON 2y ago
    I agree with the general sentiment (estimation is part of the work, ppl are not good at estimates, ppl are not good at their job) I also think that in high churn rate companies, or where team get created and disbanded every two quarters, it’s quite difficult to have a mental model on other teams ability to deliver a dependency for your team. And this situation I find quite common tbh
redleggedfrog 2y ago
You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field. As for software development being special, I really hope that what I've described above is like other engineering disciplines, and we're not special. I don't want to be special, I want to be an engineer, like those who work with aircraft or bridges and what not. I feel like in those fields the concept of estimation is a little more respected. But I'm probably wrong. :^) I'll mention I've been a professional software developer since the early 90's, not that experience equals veracity. But I've had good success using the system above, and even though the bad managers to good managers was pretty even during that time, the company experienced outstanding success during my tenure (20 years!). In the end, bad managers never last. Good managers, who take reasonable estimates to their superiors, succeeded, where managers who brought "It'll be done July 1st" got doubted because their superiors know it really doesn't work that way.
- bdangubic 2y ago
  your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you? I worked at two places that gave huge bonuses when deadlines were met (based on “estimates”) and wouldn’t you know it sh*t always got done on time and people got paid.

mewpmewp2 2y ago

It really depends on what you are working on. When I did agency type of work, building things you have built before, from scratch, it's easy to estimate. E.g. some sort of e-commerce website from scratch. On the other hand, working in a large corp, with massive legacy systems, unknown domain knowledge and dependency on other teams, it becomes near impossible. What might have been a 2 hour task in agency, might either be completely impossible during our lifetime unless the whole company was built from scratch or take 2 years. You might need 6 other teams to agree to make some sort of change, and you first might have to convince those teams, and then 2 teams will initially agree to it, then pull out in the last moment, or realize they can't do it.

bdangubic 2y ago
In your 2nd example of a large corp I can see myself joining and not knowing anything about all these potential landmines etc… but if I was at that corp for say 2-3 years those would all be known things, no? And hence estimates can come with number of assumptions based on 6 other teams doing whatever it is that they need to do etc…? But I totally agree with your point and would not be disappointed if someone missed an estimate in that sort of chaos. My comment was not really geared towards chaotic organizations but general sense (especially in myriad threads on this forum) that SWEs think that somehow our profession is so “special” that we cannot possible know how long something will take. I simply do not accept that and personally believe that more likely vast majority of SWEs simply suck at their job. there are roughly 4.5 million of us, how many are really good at their jobs (big part of which is estimation)? probably like 0.4% :)
- WOTERMEON 2y ago
  I agree with the general sentiment (estimation is part of the work, ppl are not good at estimates, ppl are not good at their job) I also think that in high churn rate companies, or where team get created and disbanded every two quarters, it’s quite difficult to have a mental model on other teams ability to deliver a dependency for your team. And this situation I find quite common tbh

redleggedfrog 2y ago

You can't make accurate estimates that can be used for deadlines for non-trivial work. You can make educated guesses on how long specific things will take, and it might be a pretty good guess if you've been keeping metrics on your past work, including things like vacation days and other similar disruptions as well, and keeping a team together long enough to have solid institutional knowledge on your code-base. And you can respectfully lay these numbers out to a manager in the form of, "This will probably take 1 to 3 days," or for bigger stuff, "2 to 3 weeks", and so on. And the manager can take the sum of all this and say, "The soonest it can probably be done is 3 months, but most likely it'll be 4, with a small chance of a bit longer", or whatever, you get the idea. And then the mangers can set the deadline as they see fit. Now, for some reason, many managers just look at the first number and are done - that's the due date. And then after that they get deer in the headlights treatment, so the worst case becomes the best case. That's on them. If they don't understand that software estimation isn't an exact science they're in the wrong field. As for software development being special, I really hope that what I've described above is like other engineering disciplines, and we're not special. I don't want to be special, I want to be an engineer, like those who work with aircraft or bridges and what not. I feel like in those fields the concept of estimation is a little more respected. But I'm probably wrong. :^) I'll mention I've been a professional software developer since the early 90's, not that experience equals veracity. But I've had good success using the system above, and even though the bad managers to good managers was pretty even during that time, the company experienced outstanding success during my tenure (20 years!). In the end, bad managers never last. Good managers, who take reasonable estimates to their superiors, succeeded, where managers who brought "It'll be done July 1st" got doubted because their superiors know it really doesn't work that way.

bdangubic 2y ago
your comment is exactly what I am talking about. you actually CAN make accurate estimates for non-trivial works. try to envision this - I hand you a non-trivial assignment to estimate with a condition that if you meet your estimate -/+ 5% you get 7-figure bonus. alternatively if you do not you get fired. after working 30 years in the biz you tell me which of the two is happening for you? I worked at two places that gave huge bonuses when deadlines were met (based on “estimates”) and wouldn’t you know it sh*t always got done on time and people got paid.