4 ms·

> 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

> 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 17y 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 17y 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.
- markdennehy 17y ago
  >In civil engineering the stakes are high, people will lose lives. If you're building a bridge, yes. But it's not always so critical. This holds in software engineering as well - If you're mucking about writing the next tetris, odds are, noone's going to die if you stuff it up. If you're writing embedded code in a medical device, lives definitely are at risk (and if you step back and look, not only is embedded code the majority of deployed code out there, but it also has some of the most mature development practices - not everything in software is agile) The problem arises when you try to draw the line between those two extremes - for example, who knew people were daft enough to follow GPS instructions that navigated them under bridges that were obviously too law, or off piers into harbours, or into oncoming traffic on one-way streets or onto train tracks (complete with oncoming trains). The criticality of the system you're developing isn't always a simple thing to determine. And don't forget - history has recorded very very similar arguments to yours that claim exactly what you're claiming, while arguing that mechanical engineering will never go from art to science...
anonjon 17y ago
126 years and the scope of the problems solved. You give an excellent example of the scoping issue: Someone can write a computer program that will run detailed mathematical models of a bridge and cross-check against established data. I can also write a program to simulate flutter, run simulations of car engines, the power grid, the stock market (You can program almost anything imaginable). I challenge you to write a program that will run a detailed mathematical model of a computer program and cross checks against established data gleaned from other programs. Even if you did, it wouldn't be terribly useful as it would just tell you that the program runs in such and such a way; you'd still not know if it actually does what it is supposed to do. Does it fit the problem domain, or is there some 'flutter' that you didn't know about? A lot of the improvements in reliability of engineering disciplines of the last 50 years have been because of the ability to simulate things better... mostly by use of the computer. There are therefore two types of error in a piece of software: 1. 'Stupid' error (I used the wrong units or I used the wrong function). 2. Thought error (I didn't understand the problem or I goofed in my reasoning about it). I'd argue, therefore, that the 'stupid' errors are the errors that can be solved by software engineering. (Using higher level languages, better compilers, better type systems, etc.) The issue being that there is only so much that you can actually do to solve them with software. The second set is a bit more difficult. Am I going to validate my bridge simulator by using a different bridge simulator? Sometimes we certainly do do this, and this is kind of the basis of iterative development (if each version of a program is a different program). At some point, I will need to understand Civil Engineering as well as Software Development to get my program to function as a Civil engineer would expect it to. This would imply, that at least in some domains, software engineering is the equivalent of meta-engineering. (I am programming the set of rules used by civil engineers). It gets more difficult the further away from engineering/scientific disciplines you get. What exactly would be the discipline be behind web programming or writing an HTTP server? Where can I get my thought guidelines to understand how I should think about the different problems? I'm sure that there is progress to be made in software engineering, but I'd guess the progress won't come from looking at engineering disciplines, and I'm pretty sure it is wrong to say that the only difference is timeframe.
- jamii 17y ago
  > I challenge you to write a program that will run a detailed mathematical model of a computer program... Model checking is well-established in hardware design and is making headway into software. Model checkers can verify high-level properties. For example, I am currently working on a p2p gossip algorithm. I use a probabilistic model checker to verify that the peer selection service provided by this algorithm fulfils its contract - in the steady state selected peers are uniformly distributed over the members of the network. I use a model checker because the maths involved is sufficiently complicated that I don't trust either my theoretical results or that the code matches the mathematical model I am working with.
yters 17y ago
Bridges don't process information, programs do. Pretty much no civil engineering product does information processing.

potatolicious 17y 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 17y 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.

markdennehy 17y ago
>In civil engineering the stakes are high, people will lose lives. If you're building a bridge, yes. But it's not always so critical. This holds in software engineering as well - If you're mucking about writing the next tetris, odds are, noone's going to die if you stuff it up. If you're writing embedded code in a medical device, lives definitely are at risk (and if you step back and look, not only is embedded code the majority of deployed code out there, but it also has some of the most mature development practices - not everything in software is agile) The problem arises when you try to draw the line between those two extremes - for example, who knew people were daft enough to follow GPS instructions that navigated them under bridges that were obviously too law, or off piers into harbours, or into oncoming traffic on one-way streets or onto train tracks (complete with oncoming trains). The criticality of the system you're developing isn't always a simple thing to determine. And don't forget - history has recorded very very similar arguments to yours that claim exactly what you're claiming, while arguing that mechanical engineering will never go from art to science...

anonjon 17y ago

126 years and the scope of the problems solved. You give an excellent example of the scoping issue: Someone can write a computer program that will run detailed mathematical models of a bridge and cross-check against established data. I can also write a program to simulate flutter, run simulations of car engines, the power grid, the stock market (You can program almost anything imaginable). I challenge you to write a program that will run a detailed mathematical model of a computer program and cross checks against established data gleaned from other programs. Even if you did, it wouldn't be terribly useful as it would just tell you that the program runs in such and such a way; you'd still not know if it actually does what it is supposed to do. Does it fit the problem domain, or is there some 'flutter' that you didn't know about? A lot of the improvements in reliability of engineering disciplines of the last 50 years have been because of the ability to simulate things better... mostly by use of the computer. There are therefore two types of error in a piece of software: 1. 'Stupid' error (I used the wrong units or I used the wrong function). 2. Thought error (I didn't understand the problem or I goofed in my reasoning about it). I'd argue, therefore, that the 'stupid' errors are the errors that can be solved by software engineering. (Using higher level languages, better compilers, better type systems, etc.) The issue being that there is only so much that you can actually do to solve them with software. The second set is a bit more difficult. Am I going to validate my bridge simulator by using a different bridge simulator? Sometimes we certainly do do this, and this is kind of the basis of iterative development (if each version of a program is a different program). At some point, I will need to understand Civil Engineering as well as Software Development to get my program to function as a Civil engineer would expect it to. This would imply, that at least in some domains, software engineering is the equivalent of meta-engineering. (I am programming the set of rules used by civil engineers). It gets more difficult the further away from engineering/scientific disciplines you get. What exactly would be the discipline be behind web programming or writing an HTTP server? Where can I get my thought guidelines to understand how I should think about the different problems? I'm sure that there is progress to be made in software engineering, but I'd guess the progress won't come from looking at engineering disciplines, and I'm pretty sure it is wrong to say that the only difference is timeframe.

jamii 17y ago
> I challenge you to write a program that will run a detailed mathematical model of a computer program... Model checking is well-established in hardware design and is making headway into software. Model checkers can verify high-level properties. For example, I am currently working on a p2p gossip algorithm. I use a probabilistic model checker to verify that the peer selection service provided by this algorithm fulfils its contract - in the steady state selected peers are uniformly distributed over the members of the network. I use a model checker because the maths involved is sufficiently complicated that I don't trust either my theoretical results or that the code matches the mathematical model I am working with.

yters 17y ago

Bridges don't process information, programs do. Pretty much no civil engineering product does information processing.