4 ms·

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

by 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.
  - wallflower 17y ago
    In the homework we do for engineering classes, we would be able to make simplifications without fundamentally altering the problem. For example a continuous load on a structure could be modeled as a single force vector because G, the gravitational force always acts downwards. You can't do that in software with loosely-coupled, autonomous modules. These modules do not obey anything. Just an implicit contract that can be broken easily. Unit tests only help to clarify the contract for a module or between modules. In structural engineering, there are a lot of unknowns but they can be modeled across the entire range because there are many known constants. The load-bearing capacity of the beam, the moment (the twisting force acting on the beam). Virtual abstractions like software do not obey physical rules. Because they are virtual. You can create a Castle in the Air in your program world, if you like. Hard physical reality has real constraints. Virtual reality has flexible constraints. Physical reality is one of the reasons building construction is a solved problem. The irony is with sophisticated software, architects like S. Calatrava and F. Gehry can begin to create almost Castles in the Air.
hxa7241 17y ago
Yes, software can possibly be engineered. It comes down to there being an objective, complex or sufficiently interesting, and usefully applicable material at the base. Software has this, it is just abstract: instead of atoms, it is bits and operations. A 'material' means understanding, and rules, can be formed. Instead of force mechanics, software has algorithmic complexity. Sorting's lower bound of O(n log n) would be an example of basic knowledge. Of course, with only 50 years history, understanding of software's material is immature, and there is much to be discovered. But merely assembling pieces in regular, predictable ways, is sufficient for a simple kind of engineering status. Engineering seems often conflated with process. But this misses the essentials. Process is only support. It doesn't tell you about the material, or about design. It only helps you be better organised in what you can already do. Buildings don't stand up because the designers rigidly followed a process, they stand up because there is an understanding of how forces work in structures (etc.). In a large, industrial, sense, software engineering lacks in certain ways, in certain areas. But at the core, it is essentially engineering.

by allenp 17y ago

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.
- wallflower 17y ago
  In the homework we do for engineering classes, we would be able to make simplifications without fundamentally altering the problem. For example a continuous load on a structure could be modeled as a single force vector because G, the gravitational force always acts downwards. You can't do that in software with loosely-coupled, autonomous modules. These modules do not obey anything. Just an implicit contract that can be broken easily. Unit tests only help to clarify the contract for a module or between modules. In structural engineering, there are a lot of unknowns but they can be modeled across the entire range because there are many known constants. The load-bearing capacity of the beam, the moment (the twisting force acting on the beam). Virtual abstractions like software do not obey physical rules. Because they are virtual. You can create a Castle in the Air in your program world, if you like. Hard physical reality has real constraints. Virtual reality has flexible constraints. Physical reality is one of the reasons building construction is a solved problem. The irony is with sophisticated software, architects like S. Calatrava and F. Gehry can begin to create almost Castles in the Air.

hxa7241 17y ago

Yes, software can possibly be engineered. It comes down to there being an objective, complex or sufficiently interesting, and usefully applicable material at the base. Software has this, it is just abstract: instead of atoms, it is bits and operations. A 'material' means understanding, and rules, can be formed. Instead of force mechanics, software has algorithmic complexity. Sorting's lower bound of O(n log n) would be an example of basic knowledge. Of course, with only 50 years history, understanding of software's material is immature, and there is much to be discovered. But merely assembling pieces in regular, predictable ways, is sufficient for a simple kind of engineering status. Engineering seems often conflated with process. But this misses the essentials. Process is only support. It doesn't tell you about the material, or about design. It only helps you be better organised in what you can already do. Buildings don't stand up because the designers rigidly followed a process, they stand up because there is an understanding of how forces work in structures (etc.). In a large, industrial, sense, software engineering lacks in certain ways, in certain areas. But at the core, it is essentially engineering.