5 ms·

I think that this largely misses the point. The first thing to point out is that writing software doesn't map very well onto civil engineering. In civil, your

by anonjon 16y ago

I think that this largely misses the point. The first thing to point out is that writing software doesn't map very well onto civil engineering. In civil, your base requirements are supposed to be very well defined. 'I need a bridge from point a to point b, it has to support x amount of traffic weighing y kilos'. The point of the Tacoma Narrows incident is that 'flutter' was something that was hereto unmentioned in the design requirements of the bridge. It wasn't accounted for, therefore the bridge collapsed. To imply that 'proper engineering' would have prevented the collapse is wrong. They used proper engineering... they just didn't account for everything that they needed to account for. No one is going to argue that solid design, trusted components, testing and QA are not important parts of programming. (They are good, especially the components, testing, and QA bits). What the original Spolsky 'duct tape programmer' post is railing against is the disguise of over-engineering (because of incompetence) as the above things (particularly the design part). The point being that the extremely competent don't need to disguise their software in an elaborate drapery of buzzwords and patterns. (Because they don't need a justification to fall back on if it doesnt... 'well we used x and y and z hot new thing').

potatolicious 16y ago
I majored in a traditional engineering, and I wish programmers/CS types would stop comparing programming with mechanical/civil engineering; they are completely different processes with completely different mentalities due to completely different requirements. Which is not to say there isn't some overlap - writing software for, say, a MRI machine would likely be held to the same processes and standards as most traditional engineering, but let's be honest, 99% of programming isn't that. > "The standard approach taken to minimise or prevent these unacceptable outcomes is conservative design, using trusted components, with testing and quality assurance being critical parts of the design and implementation processes." I think the blog author is out of his expertise here - this is an extremely "software" abstraction of the engineering design process. I'm not convinced the traditional engineering process works at all in software - traditional engineering is waterfall (where do you think it came from?), but unlike a bridge you rarely ever know all of your requirements and specifications up front. Also, you design 100% of a bridge up-front because you can't "iterate" a bridge, but you sure as hell can iterate a website. We push code out quickly and iterate because we can, and the consequences for system failure are minimal at best. Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. This is why I balk every time someone thinks we should be held to the same standards as traditional engineers - there's no compelling gain and everything to lose.
- markdennehy 16y ago
  > Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. Nope. You can, however, run rather detailed mathematical simulations of what the varying loads will do to the bridge and cross-check against established data. Want to know the _real_ difference between civil engineering and software engineering? About 126 years.
  - potatolicious 16y ago
    Yes, this is what civil engineers do, but it's a highly suboptimal alternative to real data, which is impossible to collect due to cost and the laws of physics. If for $200 civil engineers could test a new bridge design against real, live traffic, with no risk of injury or loss of life... you bet your ass they'd be doing it. But that's not going to happen, because we can't will multiple bridges into existence for almost no money, nor can they occupy the same space :) This is also why transit planning is often such a clusterfuck - the mathematical models behind urban growth, commute patterns, etc, are often poor predictors of what will actually happen. We've got road layout down to a pretty precise science, but that's about the limit of it. The impact of said roads and thoroughfares on the communities surrounding it, for example, are still poorly understood. Roundabout way of saying it: I just don't think civil engineering and software engineering will ever truly be comparable. The amount of consequence-free testing, combined with the ability to iterate for extremely cheaply, will never be matched by a field that must build expensive physical objects.
  - dasil003 16y ago
    Actually I rather enjoyed the article, especially the opening bit about the pursuit of popularity destroying blog value, but you can't just pretend that software engineering is just simply a form of engineering still in its dark ages (though it's obviously cruder than traditional engineering disciplines). Computer science is an extension of pure math going back thousands of years, of which civil engineering is another only slightly older offshoot. The problem spaces are simply not comparable. In civil engineering you are dealing the same constraints: physics, which can be refined to perfection because they will be used billions upon billions of times throughout history and will never change. In civil engineering the stakes are high, people will lose lives. Finally, the parameters for success are very easy to measure in advance... it's easy to calculate how much traffic a bridge will carry, and you can even render exactly what it will look like for aesthetic evaluation before construction begins at all. Contrast with software where the problem space is infinitely larger (ie. the entire realm of abstract thought vs physical space, which also makes it less intuitive by people btw). The costs of failure and repair are most often trivial (especially for web software). And the suitability of software is often not known at all until it is delivered (in this regard architecture has more in common with software engineering). You can't just hand-wave these things away by stating that software engineering is an immature discipline. Even with the exact same number of man hours behind software engineering that you have behind civil engineering, there would still be a such a tiny dent in the problem space as to leave software engineering looking primitive. It's not that no one takes software engineering seriously either, take military or NASA software. Those guys have the most advanced software engineering principles on the planet, but even there, it's specifically suited to their use case. I'm sure there's a lot we could all learn from them, but if you want Microsoft Word to have that quality are you prepared to pay $500,000 a head to run it? I agree that Joel totally threw the baby out with the bathwater in the duct-tape programmer defense, but let's not disparage the state of software engineering. It's certainly much less disciplined than other forms of engineering, but that's simply a cost-benefit tradeoff that seems reasonably close to optimal.

by anonjon 16y ago

potatolicious 16y ago

I majored in a traditional engineering, and I wish programmers/CS types would stop comparing programming with mechanical/civil engineering; they are completely different processes with completely different mentalities due to completely different requirements. Which is not to say there isn't some overlap - writing software for, say, a MRI machine would likely be held to the same processes and standards as most traditional engineering, but let's be honest, 99% of programming isn't that. > "The standard approach taken to minimise or prevent these unacceptable outcomes is conservative design, using trusted components, with testing and quality assurance being critical parts of the design and implementation processes." I think the blog author is out of his expertise here - this is an extremely "software" abstraction of the engineering design process. I'm not convinced the traditional engineering process works at all in software - traditional engineering is waterfall (where do you think it came from?), but unlike a bridge you rarely ever know all of your requirements and specifications up front. Also, you design 100% of a bridge up-front because you can't "iterate" a bridge, but you sure as hell can iterate a website. We push code out quickly and iterate because we can, and the consequences for system failure are minimal at best. Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. This is why I balk every time someone thinks we should be held to the same standards as traditional engineers - there's no compelling gain and everything to lose.

markdennehy 16y ago
> Want to try a new lane arrangement on a bridge? If you could build bridges like you build software, you'd just build two with the competing lane designs, and get half of the car traffic to drive over each. Oh wait, you can't do that in real life. Nope. You can, however, run rather detailed mathematical simulations of what the varying loads will do to the bridge and cross-check against established data. Want to know the _real_ difference between civil engineering and software engineering? About 126 years.
- potatolicious 16y ago
  Yes, this is what civil engineers do, but it's a highly suboptimal alternative to real data, which is impossible to collect due to cost and the laws of physics. If for $200 civil engineers could test a new bridge design against real, live traffic, with no risk of injury or loss of life... you bet your ass they'd be doing it. But that's not going to happen, because we can't will multiple bridges into existence for almost no money, nor can they occupy the same space :) This is also why transit planning is often such a clusterfuck - the mathematical models behind urban growth, commute patterns, etc, are often poor predictors of what will actually happen. We've got road layout down to a pretty precise science, but that's about the limit of it. The impact of said roads and thoroughfares on the communities surrounding it, for example, are still poorly understood. Roundabout way of saying it: I just don't think civil engineering and software engineering will ever truly be comparable. The amount of consequence-free testing, combined with the ability to iterate for extremely cheaply, will never be matched by a field that must build expensive physical objects.
- dasil003 16y ago
  Actually I rather enjoyed the article, especially the opening bit about the pursuit of popularity destroying blog value, but you can't just pretend that software engineering is just simply a form of engineering still in its dark ages (though it's obviously cruder than traditional engineering disciplines). Computer science is an extension of pure math going back thousands of years, of which civil engineering is another only slightly older offshoot. The problem spaces are simply not comparable. In civil engineering you are dealing the same constraints: physics, which can be refined to perfection because they will be used billions upon billions of times throughout history and will never change. In civil engineering the stakes are high, people will lose lives. Finally, the parameters for success are very easy to measure in advance... it's easy to calculate how much traffic a bridge will carry, and you can even render exactly what it will look like for aesthetic evaluation before construction begins at all. Contrast with software where the problem space is infinitely larger (ie. the entire realm of abstract thought vs physical space, which also makes it less intuitive by people btw). The costs of failure and repair are most often trivial (especially for web software). And the suitability of software is often not known at all until it is delivered (in this regard architecture has more in common with software engineering). You can't just hand-wave these things away by stating that software engineering is an immature discipline. Even with the exact same number of man hours behind software engineering that you have behind civil engineering, there would still be a such a tiny dent in the problem space as to leave software engineering looking primitive. It's not that no one takes software engineering seriously either, take military or NASA software. Those guys have the most advanced software engineering principles on the planet, but even there, it's specifically suited to their use case. I'm sure there's a lot we could all learn from them, but if you want Microsoft Word to have that quality are you prepared to pay $500,000 a head to run it? I agree that Joel totally threw the baby out with the bathwater in the duct-tape programmer defense, but let's not disparage the state of software engineering. It's certainly much less disciplined than other forms of engineering, but that's simply a cost-benefit tradeoff that seems reasonably close to optimal.