Hacker News Reader

Comment by throwaway0a5e | Hacker News Reader

When people who have dug holes in the local area before are doing the digging the frequency with which digging a hole goes anything other than "pretty much exactly as expected" is vanishingly tiny.

This applies to damn near every other task. Just because some techies don't know to look at the forecast and budget extra time for unloading trailers of material in inclement weather because this particular job site happens to be a mud pit doesn't mean that the people who's job it is to schedule those things don't know to do so.

Edit: I chose my words for a reason. Some of you people would do well to understand that not going smoothly is not the same as not going as expected. The people who dig holes for a living both know how long the average hole takes, how long the median is and how frequently "well shit we hit bedrock where we didn't expect it, now we gotta do X, Y and Z" type outliers occur.

View on HN

Not going to comment on hole digging because I am a "techie", but going to use your comment as an accretion point for a thought I've had for a while.

In software, until we acknowledge the way in which the coastline paradox[0] pertains to task estimation, we're going to continue spinning our wheels saying things like "people have worked on this area before, the estimation should be easy" and keep getting really inaccurate estimates, and the engineers will continue to be blamed.

The fractal nature of task complexity suggests that _complexity can only go up_ (more or less). This is why estimates always seem to be wrong in the direction of "too short".

Your comment about hole digging is to assert that the fractal dimension[0 again] is 1 for that particular problem. Great! Estimation is easy in those cases.

My proposal: identify the particular fractal dimension of your particular problem domain (by observing past estimations compared with their reality) and use it as a multiplicative factor in estimates.

Unfortunately, most managers call this process "sandbagging" and my proposal is considered too "mathematically complex". I believe that until this is accepted and resolved, we will continue to have unrealistic estimates.

[0]: https://en.wikipedia.org/wiki/Coastline_paradox

In big projects, there are also incentives to underbid up-front. It’s common for project managers to low-ball to get their projected funded and then use the sunk-cost fallacy to get it funded to the appropriate level. This unfortunately leaves people who actively try to give accurate estimates with unfunded projects

Yup! The change order strategy or nickel and dime strategy tho autocorrect suggested “buckle and dime” and that would also work.

Unfortunately as much as engineers and owners reps complain about this way of doing business it’s quite accepted since people generally want to keep their reputations. No one wants to be known as “difficult to work with”. So only very excessive transgressions get punished.

This just isn't true at all. Digging holes comes with plenty of fun surprises, even for someone acquainted with the qualities of the local ground. For example, in an area I worked, while doing a routine dig we uncovered a boulder the size of a Mini Cooper just below the ground surface.

I seriously don't know why people make up statements with such confidence.

Totally concur with you. It's likely the OP has never fldug a hole or have one dug. Adjacent backyards can be vastly different.

My experience in southern Indiana was that you could confidently dig a good sized hole almost anywhere with little trouble.

My experience in upstate New York is that if you can get a rock to wiggle, you can eventually dig it out. I am always surprised when wait for a cool day with a couple of hours free and then end up hitting nothing and finishing my fence post in five or ten minutes; I've spent six or eight hours digging out enough of a boulder to wrap a chain around to plant a tree.

> Just because some techies don't know to look at the forecast and budget extra time for unloading trailers of material in inclement weather because this particular job site happens to be a mud pit doesn't mean that the people who's job it is to schedule those things don't know to do so.

Of course. Because with software both halves of the estimate are hard. A construction worker knows how much time a task normally takes (base estimate), and then estimates factoring in the likelihood of the unforeseen slowing things down (adjusted estimate).

A software engineer doesn't know how long a task normally takes, as software pretty much never gets written twice the same way, so the base estimate might be wildly off - far more than any adjustment could account for. I would adjust for this when asked for high level estimates by giving my best guess and then saying that it's ±50%.

>A software engineer doesn't know how long a task normally takes, as software pretty much never gets written twice the same way

Unless you are making cookie-cutter buildings with the exact same design, the same can be said about construction.

It’s interesting talking to other engineering domains when they don’t understand why it takes so long because “it’s just software” and assumes cutting and pasting from similar problems is all that is necessary. And here we are taking the same stance.

Most buildings are close enough to cookie cutter. I used to work for a builder, he could look at a brand new house print and estimate how much it would cost to build the house within a thousand dollars. You can count the walls, stairs, and a few other features and know what it will cost because those are cookie cutter. Sure the arrangement is different, but that doesn't actually cost anything. So long it is a "stick framed single family house" it is easy to estimate because they are all cookie cutter. Change any of that and you need someone else to estimate as there are different rules for each change. Most of the changes you can make have someone who has experience and can accurately estimate it.

Or in programming terms, I can estimate how long "hello world" well take me to write. My estimate won't change if you tell me to write in it in German, so long as you give me the German translation of hello world. You can substitute any of the thousands of other languages in the world, it won't change the estimate. Of course if you tell me instead of a programming language I know I need to write it in one that I don't that will change the estimate.

This is true, but mainly because you’ve constrained both problems to a well-defined domain. Stick-built single family residential construction is nothing like building a hospital or bridge any more than “hello world” is like a business CRUD app or avionics software.

Almost all construction projects are houses, whereas no software projects are hello world.

Ok, then replace “hello world” with a website.

Would you hire someone to write avionics software because they only have web experience? They’re plenty of people who group them together because they’re both “just software” but it really just shows their ignorance rather than their understanding of the domain

That doesn't matter to this. The point is that neither task is particularly estimable due to the amount of discovery required, rather than due to the difficulty of the task.

That's a better way of putting my point, thank you. I wasn't necessarily meaning to compare the difficulty of the tasks, but rather the dissimilarity of them which leads to additional discovery effort. But on retrospect, I can see why it would come across as a comparison of difficulty.

One part that isn't mentioned that I think would apply to both construction and software is that, in many cases, estimates are backed into based on budget/time constraints involved.

In my current job, aside from tasks that are small enough (less than a day), most estimates are closer to the minimum potential time to build a feature rather than an honest estimate that accounts for the risks involved.

>anything other than "pretty much exactly as expected" is vanishingly tiny.

Anyone who has ever worked construction on a historic site (even with ‘good’ as-built drawings) can give you plenty of examples of this going wrong whether it’s running into abandoned/moved utilities, unknown geology (increasingly common there deeper you go), or a host of other examples with anything more complicated that fence post digging.

Reply on news.ycombinator.com