Live data from Hacker News

What do you mean ‘we need more time’? Project schedule estimation in software

blogs.dropbox.com

141–150 of 152 posts

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#141
post #73

Earlier quoted context omitted.

That is cherry picking. Did you try to comprehend the post you are replying to? Take into account all of the estimations, not just one failed estimation.

Sure, take into account all the estimations. How much value have they delivered? Show me how NASA has got more science done than if they had "just sent a drone there and watched what happened". Because I don't believe they have.

The funny thing is despite having the opposite opinion I understand so well how you see it. I wish I could show you my point of view better.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#142
post #4

Earlier quoted context omitted.

Underpromise and overdeliver — that's the secret to professional success.

and a rookie mistake in sales

I'd argue that promising what you can't deliver is a mistake in sales, too.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#143
post #141
post #73

Earlier quoted context omitted.

Sure, take into account all the estimations. How much value have they delivered? Show me how NASA has got more science done than if they had "just sent a drone there and watched what happened". Because I don't believe they have.

The funny thing is despite having the opposite opinion I understand so well how you see it. I wish I could show you my point of view better.

That was exactly how I felt. It is a matter of pay grade, I think.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#144
post #33

Analogies like "painting a room" are pretty useless because they are very misleading. Especially when it is an innovative product, a better analogy would be: "painting a room on Mars". With software development, there are a lot more "unknown attributes" that determine the main part of the effort estimation unless it is a repetitive task. So, a critical/skeptical engineer would always drive the customer nuts by asking…

Not a useless analogy, it gets the point across that good estimation requires breaking a task down into little steps, questioning the requirements, discovering constraints, and iterating.

The estimation process doesn't change much whether you're painting a room on earth or on Mars. If there's more uncertainty when estimating steps, you add more buffer time for instance. The goal of the exercise is to improve your estimation. Where the room is located should simply be factored into your estimation process.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#145

Earlier quoted context omitted.

When you buy something from Amazon Prime and it gets there three weeks later, I hope you are as amused by the "negotiating process." (Yes, I know, the product you build is different than manufacturing, different than construction, different than paperwork, and every other deliverable.)

Commoditised manufacture, inventory management, and shipping are pretty much precisely the opposite of software development. Or: your entirely counterfactual counterexample rather neatly proves my point.

Software development is commoditised. Or at least a lot is. Static web sites, simple mobiles apps, etc. Some individuals or organizations build them over and over with regularity.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#146

Earlier quoted context omitted.

It sounds like you are saying that when I take an hour to work on debugging something, I should spend 55 minutes taking notes on the system and where the problem might be and 5 minutes turning those notes into a coherent email. Is that a reasonable approach? I certainly prefer to think of debugging as a process of learning about a system rather that trying to try things at random without making a mental map of where…

I'm saying that when asked for a debugging estimate, you should commit to spending no more than an hour (or other amount, depending on the problem) before stopping to report on your progress. How you spend that hour depends on the circumstances; if you could predict that then you probably already know enough to give a somewhat accurate estimate. When you stop to report on your progress, you don't need to deliver deta…

usually when I debug things my method is sort of a mix of linear and binary search where I start at one place, see if the a value is what I expect it to be, then move along to a different part of the code to see if something is wrong there, reducing the search space and repeating as necessary.

Sometimes my method is instead to look at data output at a certain level of abstraction like system calls (which is usually not helpful except for detecting a network hang or a path config whose directory doesn't exist) or database queries or something. That is usually more helpful if I either already suspect I know where the problem is and need to know what model name or file name to `ag` for.

If (Hephaestus be praised) there is actually an automated test framework in place, I'll start by writing a failing test or copy-pasting an existing test and modifying it to fail, then (if it isn't JavaScript), inserting a debugger into a function the test calls.

All of this tends to be pretty successful.

But I've occasionally found myself on a project where I just have a sense that I don't know what is going on or how pieces fit together and I feel a strong temptation to stop and fix that sense of bewilderment. When I resist this urge is when it feels like I am trying things at random.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#147
post #138

Earlier quoted context omitted.

I'd guess the usage of [Waits on client to provide specs...] in the software scenario is a bit facetious. Often clients can't produce specs sufficient to build an application. Some clients may produce 'specs' which are incomprehensible, making them impossible to estimate. The crude part is, that such projects may still go on, and worse, the client may believe that the application is actually being built to the specs.

Often clients can't produce specs sufficient to build a house/building/pipeline. That's why there is an entire category of firms that exist that are hired by clients to produce these documents. Guy wants an apartment building, he hires an AE firm and tells them "I want an apartment building" and they say "well what kind of apartment building?" and then goes through the exact same process of defining scope, budget, an…

You can ask an architect or a builder how much it is going to cost to build your house. They will ask for blueprints and finishes. If the person asking doesn't have specs then the builder or architect will often offer to help them create them... For a price. Most people that want software developed want to know how much it will cost to develop software without having to invest time or money in first developing the specs. The issue is that people who what software developed either don't know too get or don't want to pay for blueprints, then they complain when things go off the rails whether cost, delivery date, or quality... They fail at managing risks themselves (by not minimally getting specs first).

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#148
post #138

Earlier quoted context omitted.

I'd guess the usage of [Waits on client to provide specs...] in the software scenario is a bit facetious. Often clients can't produce specs sufficient to build an application. Some clients may produce 'specs' which are incomprehensible, making them impossible to estimate. The crude part is, that such projects may still go on, and worse, the client may believe that the application is actually being built to the specs.

Often clients can't produce specs sufficient to build a house/building/pipeline. That's why there is an entire category of firms that exist that are hired by clients to produce these documents. Guy wants an apartment building, he hires an AE firm and tells them "I want an apartment building" and they say "well what kind of apartment building?" and then goes through the exact same process of defining scope, budget, an…

"The problem with estimates and scheduling in software engineering isn't a result of work, it is a result of failure by the project management."

The problem with estimates in software engineering is that few want to pay for them. (Which hinders the formation and demand for the category of firms to produce specs.)

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#149

Earlier quoted context omitted.

Yeah, and they'll push for four months total at a meeting a month into the project, while simultaneously changing their mind on a half dozen requirements.

Ugh. I was on a project like this. I figured that it was mostly just that specific customer...

...Unfortunately, there's a lot of "specific customers" like this.

Re: What do you mean ‘we need more time’? Project schedule estimation in software

#150
post #132

Earlier quoted context omitted.

Not pay? Heh. For work performed? OK... That is why my contracts require payment up front.

To be fair, they're talking about subpar, unacceptable work.

Or it could be solid, perfect work that meets the best possible interpretation of the contract, but the client failed to communicate what they actually wanted and perceive it as subpar and unacceptable.
Post reply on HN