4 ms·

You should spend 30 minutes talking with a project coordinator for any construction job and you'll change your mind. My company recently opened its first retai

You should spend 30 minutes talking with a project coordinator for any construction job and you'll change your mind. My company recently opened its first retail store in a new Caruso mall, and it was a considerably eye-opening experience. The pace (and cost) is frustrating, but the end result is generally fantastic and that's more than I can say for most software projects. Even for a simple job, the number of things that need to align to allow for a dump truck to deliver gravel to a construction site is non-trivial. Along with permits and what times the truck can arrive depending on whatever bureaucratic bullshit is at play, you also need to make sure the rest of the crew is in place to receive the delivery and put it to use. Don't forget about the things that need to be done even before the gravel can be delivered, and things dependent on the delivery that begin on that task is complete. This isn't a software project. A simple truck delivery being late can require dozens of people to get involved to reschedule everything else that needed to come after it - this is non-trivial, expensive, and can impact hundreds of people depending on how much the schedule slips since we often dealing with hourly labor. "But it's only changing one delivery" you say? The delivery was probably handled by a contractor, which has other clients and other responsibilities and may not be able to reschedule when it's convenient for you. Multiply this by every contractor or 3rd party you're working with and suddenly Metcalfe's law is punching you in the face. The waterfall approach exists because it works - on average - considerably better than everything else that's been tried before it, regardless of whatever cosmic forces we think are at play.

gowld 8y ago
You claim that the date and time for the glass delivery for the windows is fixed before the diggers start hauling dirt to make room for the foundation? That a construction isn't constantly scrambling to cover expected-unexpected incidents like a machine breakdown or shortstaff or a contractor screwup?
- tomnipotent 8y ago
  Not fixed, but date slippage is much more impactful in these classes of projects compared to software. > That a construction isn't constantly scrambling to cover expected-unexpected incidents like a machine breakdown or shortstaff or a contractor screwup They are, but thanks to great tooling and process they've been able to deal with it pretty well all things considered.
groestl 8y ago
I did spend a lot more than 30 minutes with a project coordinator, and complex construction projects seem to align remarkably well with software projects. Spikes, iterative approaches, severe changes in project goals/architecture while construction is already in progress, budget cuts just before the projects is almost done... it's all there. "We paid an unbelievable amount for a Gantt chart, and it was already outdated when it was delivered" he said.
- Nimitz14 8y ago
  > I did spend a lot more than 30 minutes with a project coordinator, and complex construction projects seem to align remarkably well with software projects. I don't understand how you can say this with a straight face. Material costs for software projects are nonexistent (and don't come at me with AWS blabla, it's still way less than when building physical things). Hitting delete on what you've done so far costs nothing. Construction is pretty straightforward in that even if there might be different approaches to building a certain object (like a wall), these different approaches are agreed upon (as in people agree each is a valid approach and will choose which based on the pros/cons of each). Unlike in software where there exists no agreement in how to approach a problem and each programmer out there will probably provide a different solution.
  - heavenlyblue 8y ago
    I think you're quite a bit delusional here. Construction industry and the software industry are asymmetrically different from each other in the complexities you'd need to deal with. For example, there might be many ways to do the same thing in the software industry, but you might have already dedicated yourself to proving that a given solution works "good enough". So hitting "delete" on that solution would require unmaintainable at that step amount of coordination between many teams who are using your code. Construction doesn't deal with constant changes to the laws of physics, but software industry has a churn rate of APIs of about 1 new version every 6 months, all of which need to be constantly overseen and accounted for. Did construction industry have anything like GDPR happen to it in the last 20 years?
marcosdumay 8y ago
> A simple truck delivery being late can require dozens of people to get involved to reschedule everything else that needed to come after it Looks like security people telling ops people they'll need to keep some extra data, and then coordinating with development how they are even going to collect it. Or developers moving ahead on their tasks while somebody later discovers that a schema migration will break a different application. It's not exactly waterfal that solves this kind of problem. It's the other way around, rigid specifications make the problem worse.
wpietri 8y ago
Did you read the article I linked to? I specifically gave an example of how one of the world's most prominent buildings -- far larger than a retail store -- was delivered not via waterfall planning, but flow orientation. And done on time and well under budget, something waterfall plans rarely manage to do in the construction industry? So your theory that waterfall always works considerably better is demonstrably false. As an aside, my brother builds houses, and I've spent a great deal more than 30 minutes talking with him about this. I agree houses are not software. But he agrees that waterfall thinking is often much more a problem for him than a solution.
- tomnipotent 8y ago
  Exception, not the rule. > So your theory that waterfall always works considerably better is demonstrably false. Uhmm, no? You pointed to a single building and you want to use that one exception to prove a point? Constructed during a time with considerably less federal & local bureaucracy? Seriously?
  - wpietri 8y ago
    You claimed that waterfall worked considerably better. I am offering you proof that it doesn't. Your one example is a store in a mall that you spent 30 minutes discussing. My example is the Empire State Building, which a process expert spent significant time researching. I'm open to the notion that waterfall processes work well somewhere. But my experience is generally that person in industry A says, "Oh, it really works in industry B." When I talk to somebody in industry B, they say, "Oh, I'm sure it works better in industry C." (Or, often, "industry A".) Your theory seems to be that the fact that waterfall is the now-dominant paradigm means it must be good. That was the theory in software, and still often is, despite theoretical and practical demonstrations otherwise. So it shouldn't be inconceivable that it dominates in other industries even though it doesn't work well there either.

gowld 8y ago

You claim that the date and time for the glass delivery for the windows is fixed before the diggers start hauling dirt to make room for the foundation? That a construction isn't constantly scrambling to cover expected-unexpected incidents like a machine breakdown or shortstaff or a contractor screwup?

tomnipotent 8y ago
Not fixed, but date slippage is much more impactful in these classes of projects compared to software. > That a construction isn't constantly scrambling to cover expected-unexpected incidents like a machine breakdown or shortstaff or a contractor screwup They are, but thanks to great tooling and process they've been able to deal with it pretty well all things considered.

groestl 8y ago

I did spend a lot more than 30 minutes with a project coordinator, and complex construction projects seem to align remarkably well with software projects. Spikes, iterative approaches, severe changes in project goals/architecture while construction is already in progress, budget cuts just before the projects is almost done... it's all there. "We paid an unbelievable amount for a Gantt chart, and it was already outdated when it was delivered" he said.

Nimitz14 8y ago
> I did spend a lot more than 30 minutes with a project coordinator, and complex construction projects seem to align remarkably well with software projects. I don't understand how you can say this with a straight face. Material costs for software projects are nonexistent (and don't come at me with AWS blabla, it's still way less than when building physical things). Hitting delete on what you've done so far costs nothing. Construction is pretty straightforward in that even if there might be different approaches to building a certain object (like a wall), these different approaches are agreed upon (as in people agree each is a valid approach and will choose which based on the pros/cons of each). Unlike in software where there exists no agreement in how to approach a problem and each programmer out there will probably provide a different solution.
- heavenlyblue 8y ago
  I think you're quite a bit delusional here. Construction industry and the software industry are asymmetrically different from each other in the complexities you'd need to deal with. For example, there might be many ways to do the same thing in the software industry, but you might have already dedicated yourself to proving that a given solution works "good enough". So hitting "delete" on that solution would require unmaintainable at that step amount of coordination between many teams who are using your code. Construction doesn't deal with constant changes to the laws of physics, but software industry has a churn rate of APIs of about 1 new version every 6 months, all of which need to be constantly overseen and accounted for. Did construction industry have anything like GDPR happen to it in the last 20 years?

marcosdumay 8y ago

> A simple truck delivery being late can require dozens of people to get involved to reschedule everything else that needed to come after it Looks like security people telling ops people they'll need to keep some extra data, and then coordinating with development how they are even going to collect it. Or developers moving ahead on their tasks while somebody later discovers that a schema migration will break a different application. It's not exactly waterfal that solves this kind of problem. It's the other way around, rigid specifications make the problem worse.

wpietri 8y ago

Did you read the article I linked to? I specifically gave an example of how one of the world's most prominent buildings -- far larger than a retail store -- was delivered not via waterfall planning, but flow orientation. And done on time and well under budget, something waterfall plans rarely manage to do in the construction industry? So your theory that waterfall always works considerably better is demonstrably false. As an aside, my brother builds houses, and I've spent a great deal more than 30 minutes talking with him about this. I agree houses are not software. But he agrees that waterfall thinking is often much more a problem for him than a solution.

tomnipotent 8y ago
Exception, not the rule. > So your theory that waterfall always works considerably better is demonstrably false. Uhmm, no? You pointed to a single building and you want to use that one exception to prove a point? Constructed during a time with considerably less federal & local bureaucracy? Seriously?
- wpietri 8y ago
  You claimed that waterfall worked considerably better. I am offering you proof that it doesn't. Your one example is a store in a mall that you spent 30 minutes discussing. My example is the Empire State Building, which a process expert spent significant time researching. I'm open to the notion that waterfall processes work well somewhere. But my experience is generally that person in industry A says, "Oh, it really works in industry B." When I talk to somebody in industry B, they say, "Oh, I'm sure it works better in industry C." (Or, often, "industry A".) Your theory seems to be that the fact that waterfall is the now-dominant paradigm means it must be good. That was the theory in software, and still often is, despite theoretical and practical demonstrations otherwise. So it shouldn't be inconceivable that it dominates in other industries even though it doesn't work well there either.