You're right about traditional engineers whose work has been going on for quite some time now. We more-or-less figured out the "correct" way to build a bridge or an on-ramp or most anything physical and tangible.
However, your last point is not valid because you're under the fallacy we ever got the framework problem "correct". Who is to say that Django is better than RoR or visa-versa? Software is still a very new craft; you can't say that about masonry. Actually your fallacy stems even further. You're assuming software is predictable. There's degrees of predictability, but most programming starts out as a trek into the unknown. Sure, you might grab a familiar lamp like [Framework X] to shed light along the way, but really you don't know for sure what you're in for. If you did (or do), then you probably spent an insane amount of time spec'ing everything out perfectly. I have no problem with this, but there's even some dissonance between spec & code and the further out that spec gets, the greater the dissonance.
Software will always be kinda crazy in my opinion, but I reckon we're getting better with these agile approaches that embrace the unpredictability. In the TDD approach, you have to come up with tests first. This can usually give the programmer or architect a much clearer picture than "step 1: build web app" which will transfer over into their estimates.