4 ms·

You hear this BS from time to time. Usually from some organization, or individual, that wants to make computing a "Profession". They usually neglect to mention

You hear this BS from time to time. Usually from some organization, or individual, that wants to make computing a "Profession". They usually neglect to mention the thousands of bridges, buildings, and other structures that collapse every year, or the occasional city that drowns. How many automobile or baby cot recalls were there this year? I suspect that Engineering is no more reliable than computing.

wallflower 17y ago
I studied civil engineering in school. All of my civil engineering friends are now licensed professional engineers (most, if not, all of them structural - designing and inspecting bridges). What that means, besides having a really nice seal embosser, is that when you sign-off on a design (embossing it with your professional signature) - is that you take responsibility for that design. You are professionally liable for the failure of your design. As a side note, to take the Professional Engineering exam in certain U.S. states, you have to submit 4" thick or so of your actual engineering work notes from your 3 or 4 years of professional work experience (a prerequisite to sit for the exam). Pretty much the year you sit for the P.E. exam you study for it like a part-time job (companies support you because they know the importance of it). It is not just about reliability, it is about ethics (the Citibank building case is studied) and a sense of professional responsibility. Real professions are very regulated and self-regulating (belonging to a tribe) at the same time. When I heard my sister was dating a programmer - my future brother-in-law, I had her ask him if he thought software could be engineered. And he gave me the correct response. Having been trained in structural engineering, I hate... really, really abhor the term software engineer - I prefer software developer.
- nailer 17y ago
  For those interested on the background (and wonering which Citigroup Building): http://en.wikipedia.org/wiki/Citigroup_Center http://en.wikipedia.org/wiki/Citigroup_Center 'Changes during construction led to a finished product that was structurally unsound. In 1978, prompted by a question from a Princeton University engineering student, LeMessurier discovered a potentially fatal flaw in the building's construction: The original design's welded joints were changed to bolted joints during construction, which were too weak to withstand 70-mile-per-hour (113 km/h) quartering winds.'
- allenp 17y ago
  So I have to ask then (and this is really in the spirit of discussion not trolling) - is it that software cannot currently be engineered, or is it that software can never be engineered? I ask because I feel like there are examples of "bridge-worthy" software, mostly examples out of NASA where the code tightly fits the hardware and the number of bugs per line of code is something like 1-to-1million.
  - wallflower 17y ago
    If the scope is very narrow, software can be engineered to be correct. However, I think it is better to work towards organic, self-healing software systems like Google (where they leave failed cluster nodes in place, not bothering to find or remove them). Another reason software cannot be engineered in a cost-effective manner is most engineering is based on inviolable physical rules (the constant g (gravity) - this allows software (irony, yes) to be developed that helps engineers correctly (there is always a "factor of safety") engineer (FEA software like ANSYS). My hat is off to the legends like Thomas Roebling who designed the Brooklyn Bridge before computer aid. The pain and cost of engineering software to structural engineering standards (ISO 9000 is a joke, NASA has its own internal standards) usually exceeds the lifetime benefit of correctly engineering that software. A good rule of thumb is will someone's life be jeopardized if the software fails (dialysis, automobile vehicle systems, nuclear thermal rod control, 747s, space ships (makes me wonder, actually, how "correct" Burt Rutan's X Prize spaceship software may be)).
    - hxa7241 17y ago
      > most engineering is based on inviolable physical rules Don't rules such as those of algorithmic complexity have the same status and position? They are as objectively certain -- more so, in fact, since they are purely logical. At its base, software is built on bits and operations, which are entirely determinate. The ramifications might not currently be fully understood or exploited (software is only about 50 years old!), but the potential is there. As an example: with CPUs like the Z80 it was possible to count clock cycles of instructions, and determine upper/lower/average running times of code. That would be equivalent to determining resultant forces across a whole physical structure. Today, CPU makers have made things difficult, but that is completely contingent: it would in principle be possible to predict performance, in an engineering fashion, for many purposes.
gcv 17y ago
Nonsense. While buildings and bridges certainly do fail, and they require significant expertise to design and build correctly, they do not collapse because of one misplaced bolt. One misplaced *p++? Segmentation fault. http://groups.csail.mit.edu/mac/projects/amorphous/workshop-sept-99/robust-diversity.pdf http://groups.csail.mit.edu/mac/projects/amorphous/workshop-... The real problem with people calling programming "software engineering" is that programmers have absolutely no idea which processes actually produce more reliable software. There's a lot of hand-waving and anecdotes, and no solid or reproducible results anywhere. TDD this, agile that, waterfall this other thing. All of it still produces buggy software which crashes, corrupts data, and otherwise makes programs unreliable. Relatively bug-free software is always the product of really smart people who made very few mistakes and tested thoroughly, and never the product of any particular "process" which generalizes well even to another group of smart people. (Just look at the arguments which arise here on HN every time TDD comes up.)
rm-rf 17y ago
Assume for a moment, that there is no difference in error rates for software & bridge engineering. In the case of most software engineering, there is no recall, no liability, and often no admission of liability as a consequence of software failures. In the case of 'real' engineering, the opposite is true. If a software vendor wrote a product that deleted my data because of a bug (Apple, for example) were to assume liability, refund my purchase price, and compensate me for my data and recovery costs........

wallflower 17y ago

I studied civil engineering in school. All of my civil engineering friends are now licensed professional engineers (most, if not, all of them structural - designing and inspecting bridges). What that means, besides having a really nice seal embosser, is that when you sign-off on a design (embossing it with your professional signature) - is that you take responsibility for that design. You are professionally liable for the failure of your design. As a side note, to take the Professional Engineering exam in certain U.S. states, you have to submit 4" thick or so of your actual engineering work notes from your 3 or 4 years of professional work experience (a prerequisite to sit for the exam). Pretty much the year you sit for the P.E. exam you study for it like a part-time job (companies support you because they know the importance of it). It is not just about reliability, it is about ethics (the Citibank building case is studied) and a sense of professional responsibility. Real professions are very regulated and self-regulating (belonging to a tribe) at the same time. When I heard my sister was dating a programmer - my future brother-in-law, I had her ask him if he thought software could be engineered. And he gave me the correct response. Having been trained in structural engineering, I hate... really, really abhor the term software engineer - I prefer software developer.

nailer 17y ago
For those interested on the background (and wonering which Citigroup Building): http://en.wikipedia.org/wiki/Citigroup_Center http://en.wikipedia.org/wiki/Citigroup_Center 'Changes during construction led to a finished product that was structurally unsound. In 1978, prompted by a question from a Princeton University engineering student, LeMessurier discovered a potentially fatal flaw in the building's construction: The original design's welded joints were changed to bolted joints during construction, which were too weak to withstand 70-mile-per-hour (113 km/h) quartering winds.'
allenp 17y ago
So I have to ask then (and this is really in the spirit of discussion not trolling) - is it that software cannot currently be engineered, or is it that software can never be engineered? I ask because I feel like there are examples of "bridge-worthy" software, mostly examples out of NASA where the code tightly fits the hardware and the number of bugs per line of code is something like 1-to-1million.
- wallflower 17y ago
  If the scope is very narrow, software can be engineered to be correct. However, I think it is better to work towards organic, self-healing software systems like Google (where they leave failed cluster nodes in place, not bothering to find or remove them). Another reason software cannot be engineered in a cost-effective manner is most engineering is based on inviolable physical rules (the constant g (gravity) - this allows software (irony, yes) to be developed that helps engineers correctly (there is always a "factor of safety") engineer (FEA software like ANSYS). My hat is off to the legends like Thomas Roebling who designed the Brooklyn Bridge before computer aid. The pain and cost of engineering software to structural engineering standards (ISO 9000 is a joke, NASA has its own internal standards) usually exceeds the lifetime benefit of correctly engineering that software. A good rule of thumb is will someone's life be jeopardized if the software fails (dialysis, automobile vehicle systems, nuclear thermal rod control, 747s, space ships (makes me wonder, actually, how "correct" Burt Rutan's X Prize spaceship software may be)).
  - hxa7241 17y ago
    > most engineering is based on inviolable physical rules Don't rules such as those of algorithmic complexity have the same status and position? They are as objectively certain -- more so, in fact, since they are purely logical. At its base, software is built on bits and operations, which are entirely determinate. The ramifications might not currently be fully understood or exploited (software is only about 50 years old!), but the potential is there. As an example: with CPUs like the Z80 it was possible to count clock cycles of instructions, and determine upper/lower/average running times of code. That would be equivalent to determining resultant forces across a whole physical structure. Today, CPU makers have made things difficult, but that is completely contingent: it would in principle be possible to predict performance, in an engineering fashion, for many purposes.

gcv 17y ago

Nonsense. While buildings and bridges certainly do fail, and they require significant expertise to design and build correctly, they do not collapse because of one misplaced bolt. One misplaced *p++? Segmentation fault. http://groups.csail.mit.edu/mac/projects/amorphous/workshop-sept-99/robust-diversity.pdf http://groups.csail.mit.edu/mac/projects/amorphous/workshop-... The real problem with people calling programming "software engineering" is that programmers have absolutely no idea which processes actually produce more reliable software. There's a lot of hand-waving and anecdotes, and no solid or reproducible results anywhere. TDD this, agile that, waterfall this other thing. All of it still produces buggy software which crashes, corrupts data, and otherwise makes programs unreliable. Relatively bug-free software is always the product of really smart people who made very few mistakes and tested thoroughly, and never the product of any particular "process" which generalizes well even to another group of smart people. (Just look at the arguments which arise here on HN every time TDD comes up.)

rm-rf 17y ago

Assume for a moment, that there is no difference in error rates for software & bridge engineering. In the case of most software engineering, there is no recall, no liability, and often no admission of liability as a consequence of software failures. In the case of 'real' engineering, the opposite is true. If a software vendor wrote a product that deleted my data because of a bug (Apple, for example) were to assume liability, refund my purchase price, and compensate me for my data and recovery costs........