Hacker News Reader

Comment by jhncls | Hacker News Reader

It is weird how people look at this as a NP-hard scheduling problem. That doesn't touch the fundamental issue of uncertainty. Digging a hole can take between 5 minutes and eternity, depending on whether tree roots, old cables, old reinforced concrete, possible archeological finds, ... are encountered. A delivery of new material can be held up by traffic, by unforeseen stock issues, ... . The time concrete needs to dry depends on the weather. Things would be easy if it just were a NP-hard scheduling problem that only needs to get at 0.1% of the optimal solution.

View on HN

It’s not just that, but also because the uncertainty is partly based on the scheduling order.

Installing, say, electrical conduit may be much quicker if it’s the first job than if you have to work around recently installed ductwork. This often changes the dynamic of the solution to a nonlinear problem.

This isn’t just related to new construction. If you’re trying to minimize life-cycle costs, does it make sense to install solar panels now (and potentially - within some uncertainty - reduce the life of your current roof) or wait and lose the benefit of free electricity? Factoring in volatility of labor and materials increases the uncertainty further, and so on.

> Installing, say, electrical conduit may be much quicker if it’s the first job than if you have to work around recently installed ductwork

Note that real contractors have the plumbers come in first because the pipes have to slope downhill. Then the HVAC people because while they can go around obstructions it makes for ugly duct work (which needs to be accounted for in pressure calculations), only after they are done can the electricians come in and they have to work around whatever was done.

In a perfect world, perhaps, but that's why mechanical chases are engineered in the blueprints. If an HVAC installer comes in after the plumbing or electrician & pipes or wires are in the 'no-go' zone, guess who gets to re-do their run(s)? It isn't the metal installer.

As a former res sparky, I was often the 1st sub in after the framers finished... often enough, before the framers were finished.

The problem gets worse as buildings get bigger, with more systems. A lot of larger projects use 3D renderings now to limit the number of clashes.

IDK, this sounds like a solution looking for a problem. Whether the 3d renderings will become regular tools on-site, or not, IDK, IANAn engineer. However, I have never seen 3d models utilized beyond design, the conference room or as an on-site curiosity... mostly retail big-box & small manu, and the models I have seen are coarse and often omit critical minutiae. Blueprints have been, and should always be, readily available to provide exacting details to the experienced professional(not laymen) before & during the project, already. Lots of new ideas come & go, but the application of standard practices scales up quite well in commercial & industrial applications, more so than res, as coded requirements are scrutinized by more agents and are less likely to be curtailed in the name of ease, cost cutting, aesthetics or any other gains an inexperienced actor may wish for.

TLDR: I know 3D Modelling is very useful & meaningful for design & planning. On the site, however, there are already tested tools & standards that scale quite well.

Design blueprints do not have those types of exacting details. They try, but they’re almost always needed to be modified. That’s why, even after the design phase, they’re required to deliver “as-built” blueprints.

3D renderings are definitely becoming more common, but it seems like they’re often used only when in the customer defined SoW. Similar to energy modeling in my experience.

That’s why a lot of the discussion about schedule optimization is somewhat flawed. Critical path is often constrained just as you said, they can’t be treated as a bunch of isolated job shops.

Also, I think it’s also a bad assumption to assume every construction effort is a greenfield project, just like it would be with software. Even multi-million dollar construction projects often have to work around existing infrastructure.

Sounds like software estimation

We'll just call what the construction workers are already doing a "stand-up" and have them estimate work while they're standing there. Then we'll ask them to report on progress every morning, while holding them to the original estimate. All we need to do is write a manifesto, design a bunch of indecipherable workflow charts, name our system after some sports term or silly acronym, sell ourselves out as agile construction coaches, and watch the sweet consulting money roll in.

The uncertainty doesn't have to result in people standing around though; that should [0] manifest as periods where the job site is empty because there is a short period of slack in the schedule.

And it is easy to over-sell the variance of tasks. These things have regular and predictable times with rare outliers. The challenge of scheduling them is nothing like the impossibility of scheduling a software project accurately.

[0] Lots of exceptions, yes. No I don't know anything about construction but I do know quite a bit about scheduling work.

The differences in construction are relevant here.

Construction work involves people and machinery which can’t easily move between locations the way programmers can hop between tasks. Further there are orders of magnitude cost differences between people and machinery.

The guy with a shovel standing next to heavy machinery might not actually do much labor in a given hour, but sending them elsewhere would be a mistake.

Precisely. You're describing a scenario where the variance of the task time has little to do with why people are standing around.

The tasks could have 0 variance and there would still be people standing around. Probably for the same amount of time, in practice. The situation is controlled by the cost of moving equipment around & the order tasks need to be done.

The uncertainty would manifest as periods of buffer when equipment isn't bought to site yet/men don't get bought in at all.

Obviously sometimes the situation just falls apart, but usually I'd bet the downtime would be planned and predicted.

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.

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