3 ms·

Good developers, yes. Which takes experience, given the myriad of colorful personalities, politics and more. Though I don't think it is fair the responsibility

Good developers, yes. Which takes experience, given the myriad of colorful personalities, politics and more. Though I don't think it is fair the responsibility is largely put on the developer for "underestimating" when often the corporate is big enough to have specific people gather these requirements and map them out as part of their day-to-day. That's my main problem with this advice and the article. Of course anyone wants a developer who can do both development and figure people out to bring out the most perfect estimates possible. But it's getting to a point developers are starting to be the solely responsible people on top of ever increasing technical requirements, while being given the minimum amount of practice figuring all this stuff out.

IggleSniggle 5y ago
My spouse is in healthcare, and at least in the US, it seems to be a similar situation. There’s a big medical structure. And in theory, there’s lots of folks to deal with XYZ. In practice, docs need to do YZ because they are the ones who have the right combination of training and authorization to complete the task. When more people get hired, the doc just has to communicate YZ to more people. Either the task requires nuance that is missed if you’re not the doc, or the task requires direct doc authorization at various points regardless. Doesn’t decrease their burden at all, even though there’s more people working on YZ.
- n0w 5y ago
  I think this is a great analogy. Creating a game of telephone between the stakeholders and the people developing software is often going to impede communication. The flip side of this is that a lot of technical people lack adequate soft skills to be able to do this requirements gathering well (probably the same can be said about a lot of doctors and what defines a "good" doctor).
donkeyd 5y ago
Half the time the devs don't even underestimate, it's just that they're the easiest to blame them because it'll never hurt them (according to the people shifting the blame). One time, I had to estimate a UI migration. I made the estimate and added the disclaimer that the estimation assumed X was true and Y and Z were provided. Of course, X wasn't true, because the supplier sucked and Y and Z weren't provided by the business. So it ended up taking way more time than estimated. Guess who got the blame anyway.
- nerdponx 5y ago
  It's even worse when you get pressured into giving unrealistic estimates, or even get overruled and have your estimate ignored, and then get blamed when the project runs over the estimated time. If that ever happens to you, don't wait around and suffer. Start looking for another job and save your sanity.

IggleSniggle 5y ago

My spouse is in healthcare, and at least in the US, it seems to be a similar situation. There’s a big medical structure. And in theory, there’s lots of folks to deal with XYZ. In practice, docs need to do YZ because they are the ones who have the right combination of training and authorization to complete the task. When more people get hired, the doc just has to communicate YZ to more people. Either the task requires nuance that is missed if you’re not the doc, or the task requires direct doc authorization at various points regardless. Doesn’t decrease their burden at all, even though there’s more people working on YZ.

n0w 5y ago
I think this is a great analogy. Creating a game of telephone between the stakeholders and the people developing software is often going to impede communication. The flip side of this is that a lot of technical people lack adequate soft skills to be able to do this requirements gathering well (probably the same can be said about a lot of doctors and what defines a "good" doctor).

donkeyd 5y ago

Half the time the devs don't even underestimate, it's just that they're the easiest to blame them because it'll never hurt them (according to the people shifting the blame). One time, I had to estimate a UI migration. I made the estimate and added the disclaimer that the estimation assumed X was true and Y and Z were provided. Of course, X wasn't true, because the supplier sucked and Y and Z weren't provided by the business. So it ended up taking way more time than estimated. Guess who got the blame anyway.

nerdponx 5y ago
It's even worse when you get pressured into giving unrealistic estimates, or even get overruled and have your estimate ignored, and then get blamed when the project runs over the estimated time. If that ever happens to you, don't wait around and suffer. Start looking for another job and save your sanity.