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

Ask HN: Why do software companies still insist on Estimation?

news.ycombinator.com

Post reply on HN
Print view View original

31–39 of 39 posts

Re: Ask HN: Why do software companies still insist on Estimation?

#31

Post by soulofmischief »

potamic wrote: post #16

When you hire a contractor to redo your kitchen, do you ask how long it may take? When you order food online, do you expect to know when it will arrive? When you go to your mechanic for a repair, do you want to know when you may get your car back? When you go to a lawyer to verify a contract, do you need to know when they will be done? Why should building a software solution be any different?

Each of the services you mentioned have much better constraints (distance to travel, pages to read, components to replace, etc)

They also all suffer from estimation issues in practice. Luckily these constraints set a limit on how much a competent professional can underestimate the project.

If you're asking someone to install or update some software they've installed before on a similar system, they should be able to give you a solid estimate. This has parallels with many of the services you mentioned.

If you're asking them to research, develop and test entirely new components, which is the basis of software engineering (an engineer does more than install and update packages), you should be able to understand why this is different than delivering food.

Re: Ask HN: Why do software companies still insist on Estimation?

#32

Post by potamic »

soulofmischief wrote: post #31
potamic wrote: post #16

When you hire a contractor to redo your kitchen, do you ask how long it may take? When you order food online, do you expect to know when it will arrive? When you go to your mechanic for a repair, do you want to know when you may get your car back? When you go to a lawyer to verify a contract, do you need to know when they will be done? Why should building a software solution be any different?

Each of the services you mentioned have much better constraints (distance to travel, pages to read, components to replace, etc) They also all suffer from estimation issues in practice. Luckily these constraints set a limit on how much a competent professional can underestimate the project. If you're asking someone to install or update some software they've installed before on a similar system, they should be able to…

I think you're not appreciating the complexity involved in these. Except for delivery, other tasks do involve significant discovery, research and problem solving. Delivery on the other hand is also hard to estimate. Especially when you have multiple deliveries lined up, need to plan your route, find parking, register with building security, manage obscure addresses etc.

Re: Ask HN: Why do software companies still insist on Estimation?

#33

Post by soulofmischief »

potamic wrote: post #32
soulofmischief wrote: post #31

Earlier quoted context omitted.

Each of the services you mentioned have much better constraints (distance to travel, pages to read, components to replace, etc) They also all suffer from estimation issues in practice. Luckily these constraints set a limit on how much a competent professional can underestimate the project. If you're asking someone to install or update some software they've installed before on a similar system, they should be able to…

I think you're not appreciating the complexity involved in these. Except for delivery, other tasks do involve significant discovery, research and problem solving. Delivery on the other hand is also hard to estimate. Especially when you have multiple deliveries lined up, need to plan your route, find parking, register with building security, manage obscure addresses etc.

I said:

> They also all suffer from estimation issues in practice. Luckily these constraints set a limit on how much a competent professional can underestimate the project.

Where exactly did I claim these weren't complex services? All I said was that there are more constraints on these services than pure software dev. I went further and broke software dev down into different buckets of complexity to further pare down the argument and concede that some software dev should be constrained enough for accurate estimates.

Dispensing with the straw man, what exactly is incorrect about my comment?

Re: Ask HN: Why do software companies still insist on Estimation?

#34

Post by mfuzzey »

There are estimates and estimates.

As a rough ballpark figure (1 day, 1 week, 1 month, 3 months, 6 months, 1 year, 2 years, 3 years, 5 years) estimates are doable and reasonable.

It's also reasonbable and doable to let scope be the factor rather than time. "Tell us the most important thing and we'll do that and deliver the results every couple of weeks, tell us when what you have is good enough".

You can also do fairly accurate estimates when you're basically just doing the same thing as you've already done many times or when the customer doesn't have to give much input. Most of the construction industry is like this because it's older, goverend by physics and building codes and we have a few standard models for most things. Most of the software industry isn't like that.

However for something new, where the customer doesn't really know what he wants in much detail accurate estimates aren't really possible. In this case anyone who purports to give you an accurate estimate is either lying or using extensive padding.

Customers, and non techinical people in general, have a hard time understanding what things are difficult / important from a complexity perspecitve. Often seemingly "simple" (to them) changes are actually very complex, and sometimes the other way.

Re: Ask HN: Why do software companies still insist on Estimation?

#35

Post by mfuzzey »

belfalas wrote: post #18

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-b…

No one is talking about "never delivering any working software". You definitely do need to deliver working software and should do it in increments. That both shows the customer you are making progress and (more importantly) lets them adjust their requirements as they go along.

Software is different from most other branches of engineering in that it is far less limited by physics and that the requirements are far harder to define.

For example the requirements for a bridge or a building are relatively straight forward (size, load capacity, climatic resistance etc etc). That's not to say that designing the bridge or the building is necessarilly simple (though it probably is for small bridges and houses because we have centuries of experience with them) but even for complex construction projects the requirements are relatively simple even if the implementation may be very complex (think channel tunnel or mileau viaduc).

In software there are much flexibility that most customers don't know what they want until they see it. They generally aren't capable of saying up front what they really want (and when they try to they are often wrong and end up saying "yes, that's what I said I wanted but now I can see it it's not good".

Re: Ask HN: Why do software companies still insist on Estimation?

#36

Post by rrgok »

belfalas wrote: post #18

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-b…

I almost agree with you. But I don't understand how is the programmer (Software Engineer) responsibility to produce code that hit production? This is the responsibility for project managers, product owners or whatever. Given the Software Engineer is not a one man team doing all other roles. This is like saying the UX/UI role is to decide what iteration of the design (as in visual) should be in production. No way!

Re: Ask HN: Why do software companies still insist on Estimation?

#37

Post by rrgok »

potamic wrote: post #16

When you hire a contractor to redo your kitchen, do you ask how long it may take? When you order food online, do you expect to know when it will arrive? When you go to your mechanic for a repair, do you want to know when you may get your car back? When you go to a lawyer to verify a contract, do you need to know when they will be done? Why should building a software solution be any different?

When you have health issues, for a seemingly difficult diagnose, and you call for an appointment to your doctor you ask how much time it will take to properly diagnose you? What is this your non sensical reasoning. Another example: does any movie director ask his actors how much time it will take to do a scene? Is that the job of an actor?

Keep comparing apples to oranges and we will turn Software Engineer like any other menial job. We all know it there are a lot of unknowns, like health issues, that need to be evaluated before formulating any opinion about estimation.

Stop with non sense about estimation.

Re: Ask HN: Why do software companies still insist on Estimation?

#38

Post by rrgok »

belfalas wrote: post #18

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-b…

And to add: it is not the responsibility of the software engineer to deliver a product. This is like asking an actor to be responsible for release of a movie. Why the hell people keep expanding the role of a Software Engineer? Just stop this non sense already, please.

Re: Ask HN: Why do software companies still insist on Estimation?

#39

Post by belfalas »

rrgok wrote: post #36
belfalas wrote: post #18

Why do software engineers insist on being paid when they never deliver any working software? Imagine a world in which programmers were only paid once their code hit production. My hypothesis is that estimation skills would improve at a geometric rate. Said differently: good programmers are not afraid of making estimates. This classic article says it all better than I could: https://www.kitchensoap.com/2012/10/25/on-b…

I almost agree with you. But I don't understand how is the programmer (Software Engineer) responsibility to produce code that hit production? This is the responsibility for project managers, product owners or whatever. Given the Software Engineer is not a one man team doing all other roles. This is like saying the UX/UI role is to decide what iteration of the design (as in visual) should be in production. No way!

> how is the programmer responsibility to produce code

It is about mindset. Of course I do not mean that a programmer should suddenly be responsible for "doing everything."

What I mean is, the programmer should have as their personal mission the writing of the highest possible quality code that is ready to go to production as quickly as possible with a minimum of rework. And crucially, you have to be able to provide a realistic and reliable estimate of when your work can be expected to be completed. This ability is gained through experience.

Working well with project/product/design/etc. is part of being a good programmer. It is not enough to simply be a "good dev" - you must also be able to explain what your code does, why it does it that way, and any potential tradeoffs or flaws in design/implementation. If you cannot critique your own code in this way you are not a senior engineer. When you work with other people part of being senior is being willing to be held accountable.

Hopefully this makes what I mean more clear. It is about mindset.

Post reply on HN