[nicktorba]

I thought I was over this argument because it always hits a dead end, but Hillel took a really entertaining approach with this series. Looking back, I'm almost always having this argument with other software people, but never traditional engineers. I hadn't thought much about how our stereotypes are wrong.

A great example from the second post in the series is how software people don't have experience with the unpredictability of traditional engineering projects: "Part of this misconception comes from us seeing the results of the engineering process, not the process itself. We don’t see the friction, the overruns, the delays that happen because someone built the wall one inch to the left, or when a critical supplier goes out of business. To assume that software is uniquely unpredictable is a special kind of arrogance."

This has me wondering why the software world is so unpredictable in the first place and why we aren't working on that? Or at least getting better at dealing with it. Also, why are we so inclined to think the physical world is so predictable? Probably because we spend so much time on our computers...

excited to finish the rest of this series

[mLuby]

> This has me wondering why the software world is so unpredictable in the first place… Also, why are we so inclined to think the physical world is so predictable?

Ignoring time spent designing, software's manufacturing time is essentially zero. Compare that with days/weeks for devices and years for vessels/structures. So because we're used to the latter timescale, the pace of software feels like watching a video at 100x speed.

If engineers could instantly and cheaply print each new version of the airplane or bridge they're tasked with building, they'd start looking a lot more like the software industry. When software doesn't have its rapid/free iteration superpower (as in the early days or in must-never-fail situations), it starts looking like traditional engineering.