11–20 of 59 posts
While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
Earlier quoted context omitted.
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…
I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
The biggest pet peeve is when I give an estimate such as "I don't currently see a reason why we can't deliver X by the end of next week, assuming no other priorities come up." Of course something more important comes up in the mean time and I get scolded in a large meeting with a statement such as "You promised me I'd have X by Friday!" — this is especially infuriating when it is the PM's other project that is the higher priority interruption.
They’re all late because customers are fools and salespeople are liars. Customer: “how long will it take (and therefore cost)?” Three vendors: “less than [the other 2 vendors].” ...iterate until “cheapest” solution is reached ... meanwhile the technical staff at the vendors are losing their minds at the sales team, telling them that what they’re specifying is impossible... Customer, to vendor [cheapest]: “Here’s a co…
While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…
Then I make more promises and estimates, playing the emotional card of "sunk cost" to convince upper management to continue funding the team rather than torpedo the project. Then we ship, and I quickly get everyone on my team promoted "because we shipped" before it becomes clear to upper management that we shipped something essentially worthless to the company. Because we're in a huge profitable company, everyone can jump ship to the next shiny thing, and whoever is left holding the potato on its way to deprecation just gets re-org'd when it gets canned.
I know it's a bullshit game. But I play it well, and all the software developers on my team get paid and promoted because I am so good at it.
While much of this is true, I think it also leaves out a very common cause of software being late, perhaps the most common. The time it will take is unknown, in some cases unknowable, and no one is willing to say so. "How long will it take?" (equivalently, "Can you do this feature set by this date?") The only honest answer is: "I don't know." Nonetheless, a date gets put on it.
Disagree. Upper and lower bounds can be realistically estimated. Whether the estimates meet the demands of the market is another question. I'm an engineer, not a CEO or sales person, but I'm a firm believer in selling first and building it later. Building it after it's been promised is one of the best ways to limit scope.
Please elaborate! :)
Earlier quoted context omitted.
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…
As a manager over a new project with a ridiculous release date, I'm subject to the same political bullshit as everyone else. At this point, I'm of the opinion that anything with a realistic ship date simply won't get funded. So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place. From that poi…
Will you then argue that all new projects should avoid deadline dates, that no project should have anything other than an MVP and a iteration plan after that?
How do we change the expectations?
Earlier quoted context omitted.
I have, on more than one occasion, said so, and the response was always bafflement or annoyance, and in either case and unwillingness to accept that answer. When I was younger, I would eventually give a guess, along with a "...but that's just a guess". Nowadays, I don't even give that, because the caveats get forgotten/ignored.
I have this sort of discussion, at minimum, three times a week (we're in-house developers). Very often the project scope isn't even defined and upstream dependencies are known to be critically lacking and will need to be augmented to even perform the work. Yet we're always pressured for dates and the caveats given are immediately forgotten and almost never communicated. The biggest pet peeve is when I give an estimat…
In short it sounds like you don't have the power to say no - but actually you do.
If you can't do that, then you are the one to blame for tge project. If you did, though, then youre free to crash and burn happily ever after.
Earlier quoted context omitted.
and no one is willing to say so. Except most engineers are perfectly willing to say so in my experience but management decides to ignore them or force them to say a made up number promising falsely not to hold them to it. Even worse what happens very often is an engineer would give an estimate and then a manager would "bully" it down to a lower number. On the reverse of course it makes sense to have estimates otherwi…
As a manager over a new project with a ridiculous release date, I'm subject to the same political bullshit as everyone else. At this point, I'm of the opinion that anything with a realistic ship date simply won't get funded. So all I do these days is commit to things that I am certain aren't achievable in the time frame on the table, just so that we can get the project off the ground in the first place. From that poi…
This way, we can accept that we're all terrible at estimates but we do our best not to paint ourselves into corners because of our terrible terrible estimates.