Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Why software projects take longer than you think – a statistical model

erikbern.com

Post reply on HN
Print view View original

241–250 of 324 posts

Re: Why software projects take longer than you think – a statistical model

#241

Post by ben509 »

cs02rm0 wrote: post #90
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

I find you have to do this, but it can damage professional relationships. Recently I've flat out said no, as gently as I could, to doing some work - porting a software stack to run on Windows. A customer is asking for an estimate to do it, because a project manager who wouldn't be developing or supporting (or even using) the system likes Windows. The sales manager isn't thrilled with me over it. So he's asked the tea…

> ... it's difficult politically.

The thing to understand about politics is you can do everything right and still lose.

Here, the damage was already done by their unrealistic expectations. You were either going to accept the job, fail and make them angry, or reject it and make them angry.

Sometimes your least worst option is to cut your losses.

Re: Why software projects take longer than you think – a statistical model

#242

Post by depressed »

nahname wrote: post #104
Aeolun wrote: post #79

Earlier quoted context omitted.

> But when you advocate clearly for your needs as a professional, people are generally reasonable. This has not been my experience. People want ‘estimates’ at all costs, tell you to not worry about any accuracy, and then a week later tell your manager you committed to x date.

As long as software is a cost center to your company, it will be treated this way. Trying getting a job at a company where software is a core concern. Ideally with a CEO that is not from a marketing/business background.

I have watched a manager with a master's degree in computer science pull this BS. At an enterprise technology company. He would go as far as repeating a question over and over until he got an answer he liked.

The senior members of his team had a culture of eighty hour work weeks. Draw what conclusions you may.

Re: Why software projects take longer than you think – a statistical model

#243

Post by ben509 »

danmaz74 wrote: post #123
cs02rm0 wrote: post #90

Earlier quoted context omitted.

I find you have to do this, but it can damage professional relationships. Recently I've flat out said no, as gently as I could, to doing some work - porting a software stack to run on Windows. A customer is asking for an estimate to do it, because a project manager who wouldn't be developing or supporting (or even using) the system likes Windows. The sales manager isn't thrilled with me over it. So he's asked the tea…

An alternative to flat out saying no is to point out how expensive and risky what you've been asked would be, in terms of development time, maintenance, and other metrics that the business cares about. Even very rough estimates with a list of risks will usually do. If somebody else comes out with a much lower estimate, ask them what they think about risk A, B, C... if you've got a point, this will usually work.

If you do this, identify beforehand what you think is non-negotiable. Because it won't be a technical discussion, it will be a negotiation and you're liable to be committed at the end of it.

Of course, once you're holding certain things as non-negotiable... you're saying no.

Re: Why software projects take longer than you think – a statistical model

#245

Post by jshowa3 »

golergka wrote: post #172
jshowa3 wrote: post #132

Earlier quoted context omitted.

It actually is a problem with them because when someone asks "Does it really take that long?", they're implying that it shouldn't. Of course, in reality, they have no idea either and if they're asking you how long it should take, they should accept your answer, not try to weasel out less time. But are they ever going to admit that they have no idea and accept your estimate on face without playing BS mind games? Proba…

Explicit is better than implicit. Asking is better than guessing. If you think that someone is implying something, ask them. In most cases, people who ask "Does it really take that long?" are giving you their first emotional reaction and haven't actually thought it through deep enough to decide to manipulate you. They're upset and they want to make sure that they understood you right - which is a thing people often d…

Your manager cares about the product, he's emotionally invested in it and wants everything to go as fast as possible - it's not a bad thing!

If he was emotionally invested in the product, wanting everything to go as fast as possible is not necessarily a good thing. I can make things go as fast as possible, but then the questions become no unit tests? no integration tests? spaghetti code?

And this isn't a response from a few go around either. This is often the first thing that comes out of their mouth, right at the beginning of the project.

What happens is as follows:

1) Your manager has software development background and uses it as a superiority contest to show how much better they are than you. His lack of awareness regarding variable skill level or lack of knowledge of an existing system seems to factor little into the question. So one could argue the manager could be more empathetic in this case.

2) Your manager knows nothing about software development and really has no business asking such questions in a condescending manner. So they either pretend to know or they promised someone higher up the chain even though they had no idea, but were scarred to say so, thus the cycle has completed.

3) Your manager has a calm, rational head and accepts your estimate, your explanations, and has a good understanding of the product to negotiate with you in terms of requirements without getting emotional. The manager trusts understands that your estimate is, more than likely, not going to be accurate but accepts the changing winds and doesn't hold you to the fire.

I totally agree its better to be explicit. Which is why it matters to avoid overly emotional reactions and accept what people tell you so hand waving can be avoided.

But this is more of a prevailing problem in software requirements in general. It's rare that developers get projects with clear ideas on what needs to be done because of the ignorance or unknowns in questions that need to be asked in order to deliver a product. Often the developer has to decide, and when they do and its wrong, then they have to fix whatever they decided because no one explained, or bothered to explain, how something was supposed to work in the first place.

Re: Why software projects take longer than you think – a statistical model

#246

Post by Bartweiss »

snarf21 wrote: post #130
undergrowth54 wrote: post #29

An important aspect of being a professional software engineer is having the backbone to sometimes say things like: - “I don’t know yet enough about the problem to give you even a rough estimate. If you’d like, I can take a day to dig into it and then report back.” - “This first part should take 2-3 days. 5 on the outside. But the second part relies heavily on an API whose documentation and error messages are in Chine…

I agree with you but like others have said, they want a date they can sell to and in the end it will be your fault. It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much. I read something once that has stuck with me. "We can never give more than a vague guess because we are literally building something that d…

> It isn't just software that goes double, look at most custom building projects or government contracts. Most everything takes twice as long and costs twice as much.

There's definitely a correspondence here, but it's a bit indirect.

Government and even private contracts are often knowingly lowballed to secure the deal. Rules like "must choose lowest bid" reward entering an unrealistic bid and then inflating costs after work is going. Or, if overruns come with sufficient penalties, doing work at a loss and then charging a fortune to support a fragile and proprietary result.

In the metaphor to non-contracted software, developers generally don't correspond to the contractors but to the government. Sometimes blown estimates are simply errors, but other times somebody wanted to secure customers, so they pitched an unrealistic scope and arranged to make the inaccuracy land on the programmers. Where the government ends up with late delivery or runaway costs, programmers end up working crunch time or sacrificing quality. And where the government ends up locked into paying for support, programmers end up locked into maintaining rushed, tech-debt-riddled work.

(As for pushing sales for revenue and contract estimates, do it! Some of the most productive teams I've been part of have been ones where sales applied this pressure, but also responded well to the reverse version and kept everyone informed.)

Re: Why software projects take longer than you think – a statistical model

#247

Post by afarrell »

commandlinefan wrote: post #158
afarrell wrote: post #61

Earlier quoted context omitted.

There is a type of negotiation that can be done: Negotiation about scope. Work doesn’t get compressed. But stakeholders can identify non-essential business-facing features and cut scope. Note well: Automated testing is almost certainly essential. If someone says you are “building an MVP”, then make sure it is an actual MVP. Make sure you have a clear market hypothesis to test and check that it couldn’t be built out o…

> Negotiation about scope. I used to work for an online travel site - before every project kicked off, the business analysts would produce requirements documents that always started with a "flexibility matrix". The flexibility matrix had three rows labeled "schedule", "scope", and "resources" and three columns: "flexible", "moderately flexible" and "inflexible" and they were supposed to check one option for each row.…

Wait, how are resources flexible here? You can’t just scale the number of engineers on a project quickly..

Re: Why software projects take longer than you think – a statistical model

#248

Post by Farradfahren »

Frankly, where does this obsession to plan to force others to guess about there time originate? From a honst wish to know project time? No, for that you simply would have to take the jobs apart, looking for stuff never done before. After that you know how much your estimate can be right and wrong.

But you want your developers to feel bad and put under pressure by themselves, thats why it has to be them, who guesstimate the unknowable.

Re: Why software projects take longer than you think – a statistical model

#249

Post by ben509 »

SiempreViernes wrote: post #109

Fits symmetric function to clearly asymmetric distribution Author: Decent fit, in my opinion! This bad fit makes me genuinely sad (；∩；)

He could probably tweak a skew normal distribution to make it fit nicely, but it's pretty close to normal.

Re: Why software projects take longer than you think – a statistical model

#250

Post by ben509 »

temp269601 wrote: post #116

How about making the manager estimate the project, that way if the deadline is not met, the manager receives the blame? It's the manager's job to manage resources, and if the deadline is not hit, then they can hire/bring on more resources. If an engineer works as hard as they can for 40 hours a week, why is it the engineer's fault if the arbitrary deadline is not met? If the engineer estimate's time for a project, th…

The manager does receive the blame, and then stuff rolls downhill.
Post reply on HN