5 ms·

Please stop comparing software with real world objects. While popular the comparison between cars and computer programs are not well chosen. Actually comparing

by doc4t 14y ago

Please stop comparing software with real world objects. While popular the comparison between cars and computer programs are not well chosen. Actually comparing software to any physical object is point-less. These two only have anything in common on the surface. If you were to make software require the rigorous testing that physical products like cars undergo you would likely never be able to ship anything. If you did the customer would not be willing to pay the price. Software is infinitely more complex than even space shuttles. The number of possible combinations which you program can traverse is so big it doesn't make any sense. You could of course start proving mathematically that your software will always behave correctly. This would require you to use a language which facilitates such a method like erlang. No more web development in PHP, Ruby, JavaScript or anything else which relies on probabilistic garbage collection. I guarantee you that once you spend the money having your code proven your costs are so high that no one will buy your software. In stead they'll turn to the competitor who wrote it in VB and accept their EULA and live with any errors. The nature of software is not the same as of physical objects. You can either accept this and plan accordingly or you can betray yourself and keep getting angry about bugs.

krschultz 14y ago
"Software is infinitely more complex than even space shuttles" Hardly. I write software for fun, everything from low level drivers up the stack to web apps. My job is engineering mechanical systems more complex than the space shuttle - and with more lives at stake. The two are not even remotely comparable.
- nitrogen 14y ago
  doc4t's next sentence ("The number of possible combinations which you[sic] program can traverse is so big it doesn't make any sense.") is critical in understanding the sentence you quoted. Writing software is not so complex, but guaranteeing its operation is insanely complex.
  - krschultz 14y ago
    And how is that different from a mechanical system? We have fatigue/vibration, corrosion, and wear. What's the equivalent in software? There is a reason they park perfectly good airplanes in the desert - we can't gaurentee they won't fall out of the sky because it's impossible to perfectly predict fatigue. And I have issues all the time related to things failing 3 or 5 years after they were built (yet they have a 40 year design lifetime). Metals always seem to find a new way to corrode and bearings find new ways to fail. There is no equivalent to a corrosive, hostile, environment in software. Not to mention the random things thrown at you in the physical world. If you design jet engines, be prepared for birds to get sucked in (hopefully not too many, and if so, hopefully your pilot can land in a nearby river full of ferries to pickup the passengers). If you design buildings, get ready for earthquakes of unknown size, hurricanes of unknown wind speed, and terrorists with various methods of taking your structure down. We can't gaurentee anything. In fact we can barely test most of the complex stuff because it's too expensive. Cars are cheap relative to most things. They don't crash 737s to find out what happens or shake an entire city just to ensure that it is built correctly. You have to predict all of this stuff using calculations and it largely goes untested.
    - pwang 14y ago
      > And how is that different from a mechanical system? Most mechanical components obey underlying physical principles that have linear or quadratic approximations, at least in certain regimes of environmental and other factors. Therefore, we can model the component and we can know when we are unable to model it. We manage overall system complexity via physical/mechanical modularization, with things to insulate against thermal, mechanical, chemical, electrical coupling. By testing individual components, we have basic assurances on overall system behavior. Software attempts to do this with "good design principles", but the truth of the matter is that just about any software component in a typical application can completely jack up the global environment for other components, and processes can make OS and environment modifications that completely break other processes belonging to the same user. Try issuing performance guarantees on an airplane whose fuel pump can set μ0 and ε0 to -1 if the ground crewman that filled the wing tanks was named "Bob Null".
- doc4t 14y ago
  I never did any mechanical engineering so I trust your statement. It's still a good example when trying to convey the complexity of software to people who don't understand computers since most have an idea that space shuttles are very complex (which they of cause are) My point was that that testing all possible combinations of how your app can execute is next to impossible unless you are willing to cough up a serious amount of money for rigid mathematical proving. Which would then make it too expensive.
  - krschultz 14y ago
    I think it does a disservice because it overlooks the fact that people have figured out how to solve these problems. All engineers are human. Whether you are working on a space shuttle, an airliner, a nuclear power plant, or an iPhone app, you are a human. Humans make mistakes. Humans overlook things. So how do we engineer really complex systems with hundreds or thousands of lives at stake to an exacting standard - knowing that the engineers are human? The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process. I know a lot of guys who love to wrench on cars. They swap parts, add horsepower, change out the suspension, etc. They can build a really fast car. But that's not mechanical engineering. They are mechanics. In a lot of ways writing software is like that. Glue together some libraries and APIs the same way a tuner supercharges an engine. But that isn't engineering. Obviously we don't need the rigour of the space shuttle to make an iPhone app, but if your application calls for that complexity (or your budget/liability is large), then you need to bring in the process mechanical engineers have been using for the last 60 years. That means multiple people checking all the code. That means a well planned out arrangement/architecture. That means testing the individual parts thoroughly and the whole system together. And it means very specific configuration managament of every dependency. It's not impossible, it's just not the willy-nilly fun part of hacking stuff together. It's the ugly paperwork inducing lame part of working in a big company. But that process if done correctly helps catch mistakes.
    - doc4t 14y ago
      "The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process." I agree. I'm not sure it ever will. But comparing software to a car and the relationship between the buyer and seller is too simplified. Software have bugs. Many more bugs than cars. Because it's not tested properly. Which we don't do because no one would buy it at the price which comes from proper testing. You can accept this and write your contract accordingly or you can sit down, muck and be disappointed when it fails. I'm not saying it's right - it's just how things are.
- Nrsolis 14y ago
  There was actually a great story of the Space Shuttle software engineering team and their development practices. Generally speaking, they wrote code with zero bugs. Like...NONE. For 25 years. They did it with an almost insane level of attention to detail. http://www.fastcompany.com/magazine/06/writestuff.html http://www.fastcompany.com/magazine/06/writestuff.html So it certainly is possible to do.
  - clebio 14y ago
    Thanks for that link. I really like krschultz's parent comment and your follow up. Does anyone know how to get a single-page view of that article, though?
    - Nrsolis 14y ago
      http://www.fastcompany.com/node/28121/print http://www.fastcompany.com/node/28121/print
  - Tloewald 14y ago
    The process maturity index which used NASA/JPL as its exemplar was the big IT management fad of the late 90s (it dovetailed nicely with ISO9000 TQM) before XP and then Agile became popular. In a sense, the problem with Adobe seems to me to be the alignment of organizational goals with user benefits, and not software process.
- haberman 14y ago
  I don't have any experience with engineering mechanical systems, but I think there are at least aspects of software that are more complex than building physical things. Software is expected to scale by many orders of magnitude in many dimensions. The equivalent would be a vehicle that supports carrying between 1 and 1 million people, can travel anywhere between 1 and 1 million mph, running off fuel between 1 and 200 octane. Physical objects are never expected to support such wide scaling parameters, and yet this is very common in software. Software is also expected to run on lots of different kinds of hardware with different features and performance characteristics. A rough analogy is a physical design that has to support being constructed from either aluminium or steel. Since software is more abstract in nature, you'll often hear people saying that they weren't even sure what they were building until version 2. The requirements are also more likely to change during the engineering process. Mechanical things seem more likely to have a well-defined purpose and scope throughout the engineering process.
  - krschultz 14y ago
    Eh, I don't really buy any of that. Have you actually worked in the mechanical engineering world? I feel like it's far more gray than software engineering. I might have a specs on the output, but the environment is the actual physical world with all of its problems. Corrosion, temperature, vibration, dirt, dust, etc. It just screws with you the entire time. The abstract environment of a computer is tame in comparison. The only thing you have to worry about is the dependencies - which is basically configuration managament. Configuration managament is a problem in the mechanical world too. Except if you design a power plant to Rev B of the drawing, and show up with a Rev A drawing part that doens't fit, you might be out millions of dollars and months of times because there is no 'recompile' button when it comes to giant machined parts. As for your specific examples, 'different kinds of hardware' is no different than saying my system needs to work at -30F and 130F temperature. Materials behave very differently at different temperatures and we have to account for that. Some metals are weaker in temperatures as high as +25F. That's something you will see all the time. You are also vastly over-rating the complexity of scaling. It's really not that hard. Are you really going to tell me it's harder to figure out how to scale a web site than it is to build a rocket engine? Because there are about 1,000 web sites out there with millions of users and only about 10 organizations building rockets.
perfunctory 14y ago
> This would require you to use a language which facilitates such a method like erlang What's wrong with that?
- doc4t 14y ago
  Absolutely nothing - I just assume that the majority of web devs (myself included) would find it hard to port their software to erlang.
andos 14y ago
The OP are not comparing cars to software. They are comparing the natures of the commercial relationship between the owner and the car manufacturer and between the user and Adobe. Expecting free "recalls" from Adobe is not unreasonable.
- Smerity 14y ago
  Exactly. I was not saying software should be theoretically guaranteed -- the responder just assumed that. Adobe has a fix to a serious vulnerability. Not releasing it when the cost to them is tiny is essentially criminal negligence, especially when they say the fix is available to those who are willing to pay... This is the same company that owns Flash which runs on >99% of the desktop machines connected to the Internet.
mrmagooey 14y ago
You point out that real world comparison is pointless, fail to elucidate why, and then go and make some of your own comparisons with the space shuttle program...
- doc4t 14y ago
  "fail to elucidate why" Ok. The possible combinations of the way your application can (theoretically) run far outnumbers the estimated number of atoms in the visible universe - even for small programs. You just need a couple of loops in loops. If your program don't have it then I'm sure Node, Apache, Postgres, Rails whatever have plenty. While many of these combinations may never happen you would still have to provide proof of all of them not causing your program to go into a state which you can not handle. "and then go and make some of your own comparisons with the space shuttle" This was a comparison of complexity - not a direct comparison between the two.
  - statictype 14y ago
    The possible combinations of the way your application can (theoretically) run far outnumbers the estimated number of atoms in the visible universe - even for small programs. You just need a couple of loops in loops. Can you elaborate on this? I'm not convinced that this is true (but am willing to be proven wrong)
    - doc4t 14y ago
      I ment the whole stack...not just a single fizzbuzz snippet. As I see it this is what is going on when your users use a webapp. The user runs some client code which you wrote. In a browser which other guys wrote. Running on an OS made by some one. Sending data back and forth via protocols and network equipment with software that other people wrote. You server OS receives the request and passes it to your load balancer which distributes to Apache which forwards to PHP which routes to SQL...and all the way back. With the millions and billions of lines of code involved in these steps it could likely be a number of this magnitude. Actually it's a wonder that it works...
luriel 14y ago
> Software is infinitely more complex than even space shuttles. That is not an inherent property of software, the problem with software is that it makes it all too easy to hide complexity, and that some of the costs of complexity are not superficially apparent. Add on top of that how in the name of 'reuse' we pile more and more layers of complexity, and you end up with systems that are humanly incomprehensible. But this doesn't mean that writing simple yet functional software is not possible, it just requires much more care, thought and self-discipline. The two top quotes listed here are worth remembering: http://quotes.cat-v.org/programming/ http://quotes.cat-v.org/programming/ "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." — C.A.R. Hoare "The computing scientist's main challenge is not to get confused by the complexities of his own making." — E. W. Dijkstra Most software complexity is of our (programmers) own making.
mistermann 14y ago
You seem to be arguing against consumers insisting Adobe ship defect free software as the cost would be prohibitive, which is true. But that isn't what's being discussed here. What is being discussed: when a defect is discovered in the product by the end consumer, is it a fair (or proper, or wise) business practice to charge the customer for the software patch?
- doc4t 14y ago
  No I don't think it is alright to charge for a patch. It was not my intention to side track the discussion. I just don't like the simplification of comparing with cars - but the OP made it clear that I misunderstood his post.

by doc4t 14y ago

krschultz 14y ago

"Software is infinitely more complex than even space shuttles" Hardly. I write software for fun, everything from low level drivers up the stack to web apps. My job is engineering mechanical systems more complex than the space shuttle - and with more lives at stake. The two are not even remotely comparable.

nitrogen 14y ago
doc4t's next sentence ("The number of possible combinations which you[sic] program can traverse is so big it doesn't make any sense.") is critical in understanding the sentence you quoted. Writing software is not so complex, but guaranteeing its operation is insanely complex.
- krschultz 14y ago
  And how is that different from a mechanical system? We have fatigue/vibration, corrosion, and wear. What's the equivalent in software? There is a reason they park perfectly good airplanes in the desert - we can't gaurentee they won't fall out of the sky because it's impossible to perfectly predict fatigue. And I have issues all the time related to things failing 3 or 5 years after they were built (yet they have a 40 year design lifetime). Metals always seem to find a new way to corrode and bearings find new ways to fail. There is no equivalent to a corrosive, hostile, environment in software. Not to mention the random things thrown at you in the physical world. If you design jet engines, be prepared for birds to get sucked in (hopefully not too many, and if so, hopefully your pilot can land in a nearby river full of ferries to pickup the passengers). If you design buildings, get ready for earthquakes of unknown size, hurricanes of unknown wind speed, and terrorists with various methods of taking your structure down. We can't gaurentee anything. In fact we can barely test most of the complex stuff because it's too expensive. Cars are cheap relative to most things. They don't crash 737s to find out what happens or shake an entire city just to ensure that it is built correctly. You have to predict all of this stuff using calculations and it largely goes untested.
  - pwang 14y ago
    > And how is that different from a mechanical system? Most mechanical components obey underlying physical principles that have linear or quadratic approximations, at least in certain regimes of environmental and other factors. Therefore, we can model the component and we can know when we are unable to model it. We manage overall system complexity via physical/mechanical modularization, with things to insulate against thermal, mechanical, chemical, electrical coupling. By testing individual components, we have basic assurances on overall system behavior. Software attempts to do this with "good design principles", but the truth of the matter is that just about any software component in a typical application can completely jack up the global environment for other components, and processes can make OS and environment modifications that completely break other processes belonging to the same user. Try issuing performance guarantees on an airplane whose fuel pump can set μ0 and ε0 to -1 if the ground crewman that filled the wing tanks was named "Bob Null".
doc4t 14y ago
I never did any mechanical engineering so I trust your statement. It's still a good example when trying to convey the complexity of software to people who don't understand computers since most have an idea that space shuttles are very complex (which they of cause are) My point was that that testing all possible combinations of how your app can execute is next to impossible unless you are willing to cough up a serious amount of money for rigid mathematical proving. Which would then make it too expensive.
- krschultz 14y ago
  I think it does a disservice because it overlooks the fact that people have figured out how to solve these problems. All engineers are human. Whether you are working on a space shuttle, an airliner, a nuclear power plant, or an iPhone app, you are a human. Humans make mistakes. Humans overlook things. So how do we engineer really complex systems with hundreds or thousands of lives at stake to an exacting standard - knowing that the engineers are human? The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process. I know a lot of guys who love to wrench on cars. They swap parts, add horsepower, change out the suspension, etc. They can build a really fast car. But that's not mechanical engineering. They are mechanics. In a lot of ways writing software is like that. Glue together some libraries and APIs the same way a tuner supercharges an engine. But that isn't engineering. Obviously we don't need the rigour of the space shuttle to make an iPhone app, but if your application calls for that complexity (or your budget/liability is large), then you need to bring in the process mechanical engineers have been using for the last 60 years. That means multiple people checking all the code. That means a well planned out arrangement/architecture. That means testing the individual parts thoroughly and the whole system together. And it means very specific configuration managament of every dependency. It's not impossible, it's just not the willy-nilly fun part of hacking stuff together. It's the ugly paperwork inducing lame part of working in a big company. But that process if done correctly helps catch mistakes.
  - doc4t 14y ago
    "The answer is to build a process that catches mistakes. I don't think software engineering has really caught up with mechanical engineering in terms of process." I agree. I'm not sure it ever will. But comparing software to a car and the relationship between the buyer and seller is too simplified. Software have bugs. Many more bugs than cars. Because it's not tested properly. Which we don't do because no one would buy it at the price which comes from proper testing. You can accept this and write your contract accordingly or you can sit down, muck and be disappointed when it fails. I'm not saying it's right - it's just how things are.
Nrsolis 14y ago
There was actually a great story of the Space Shuttle software engineering team and their development practices. Generally speaking, they wrote code with zero bugs. Like...NONE. For 25 years. They did it with an almost insane level of attention to detail. http://www.fastcompany.com/magazine/06/writestuff.html http://www.fastcompany.com/magazine/06/writestuff.html So it certainly is possible to do.
- clebio 14y ago
  Thanks for that link. I really like krschultz's parent comment and your follow up. Does anyone know how to get a single-page view of that article, though?
  - Nrsolis 14y ago
    http://www.fastcompany.com/node/28121/print http://www.fastcompany.com/node/28121/print
- Tloewald 14y ago
  The process maturity index which used NASA/JPL as its exemplar was the big IT management fad of the late 90s (it dovetailed nicely with ISO9000 TQM) before XP and then Agile became popular. In a sense, the problem with Adobe seems to me to be the alignment of organizational goals with user benefits, and not software process.
haberman 14y ago
I don't have any experience with engineering mechanical systems, but I think there are at least aspects of software that are more complex than building physical things. Software is expected to scale by many orders of magnitude in many dimensions. The equivalent would be a vehicle that supports carrying between 1 and 1 million people, can travel anywhere between 1 and 1 million mph, running off fuel between 1 and 200 octane. Physical objects are never expected to support such wide scaling parameters, and yet this is very common in software. Software is also expected to run on lots of different kinds of hardware with different features and performance characteristics. A rough analogy is a physical design that has to support being constructed from either aluminium or steel. Since software is more abstract in nature, you'll often hear people saying that they weren't even sure what they were building until version 2. The requirements are also more likely to change during the engineering process. Mechanical things seem more likely to have a well-defined purpose and scope throughout the engineering process.
- krschultz 14y ago
  Eh, I don't really buy any of that. Have you actually worked in the mechanical engineering world? I feel like it's far more gray than software engineering. I might have a specs on the output, but the environment is the actual physical world with all of its problems. Corrosion, temperature, vibration, dirt, dust, etc. It just screws with you the entire time. The abstract environment of a computer is tame in comparison. The only thing you have to worry about is the dependencies - which is basically configuration managament. Configuration managament is a problem in the mechanical world too. Except if you design a power plant to Rev B of the drawing, and show up with a Rev A drawing part that doens't fit, you might be out millions of dollars and months of times because there is no 'recompile' button when it comes to giant machined parts. As for your specific examples, 'different kinds of hardware' is no different than saying my system needs to work at -30F and 130F temperature. Materials behave very differently at different temperatures and we have to account for that. Some metals are weaker in temperatures as high as +25F. That's something you will see all the time. You are also vastly over-rating the complexity of scaling. It's really not that hard. Are you really going to tell me it's harder to figure out how to scale a web site than it is to build a rocket engine? Because there are about 1,000 web sites out there with millions of users and only about 10 organizations building rockets.

perfunctory 14y ago

> This would require you to use a language which facilitates such a method like erlang What's wrong with that?

doc4t 14y ago
Absolutely nothing - I just assume that the majority of web devs (myself included) would find it hard to port their software to erlang.

andos 14y ago

The OP are not comparing cars to software. They are comparing the natures of the commercial relationship between the owner and the car manufacturer and between the user and Adobe. Expecting free "recalls" from Adobe is not unreasonable.

Smerity 14y ago
Exactly. I was not saying software should be theoretically guaranteed -- the responder just assumed that. Adobe has a fix to a serious vulnerability. Not releasing it when the cost to them is tiny is essentially criminal negligence, especially when they say the fix is available to those who are willing to pay... This is the same company that owns Flash which runs on >99% of the desktop machines connected to the Internet.

mrmagooey 14y ago

You point out that real world comparison is pointless, fail to elucidate why, and then go and make some of your own comparisons with the space shuttle program...

doc4t 14y ago
"fail to elucidate why" Ok. The possible combinations of the way your application can (theoretically) run far outnumbers the estimated number of atoms in the visible universe - even for small programs. You just need a couple of loops in loops. If your program don't have it then I'm sure Node, Apache, Postgres, Rails whatever have plenty. While many of these combinations may never happen you would still have to provide proof of all of them not causing your program to go into a state which you can not handle. "and then go and make some of your own comparisons with the space shuttle" This was a comparison of complexity - not a direct comparison between the two.
- statictype 14y ago
  The possible combinations of the way your application can (theoretically) run far outnumbers the estimated number of atoms in the visible universe - even for small programs. You just need a couple of loops in loops. Can you elaborate on this? I'm not convinced that this is true (but am willing to be proven wrong)
  - doc4t 14y ago
    I ment the whole stack...not just a single fizzbuzz snippet. As I see it this is what is going on when your users use a webapp. The user runs some client code which you wrote. In a browser which other guys wrote. Running on an OS made by some one. Sending data back and forth via protocols and network equipment with software that other people wrote. You server OS receives the request and passes it to your load balancer which distributes to Apache which forwards to PHP which routes to SQL...and all the way back. With the millions and billions of lines of code involved in these steps it could likely be a number of this magnitude. Actually it's a wonder that it works...

luriel 14y ago

> Software is infinitely more complex than even space shuttles. That is not an inherent property of software, the problem with software is that it makes it all too easy to hide complexity, and that some of the costs of complexity are not superficially apparent. Add on top of that how in the name of 'reuse' we pile more and more layers of complexity, and you end up with systems that are humanly incomprehensible. But this doesn't mean that writing simple yet functional software is not possible, it just requires much more care, thought and self-discipline. The two top quotes listed here are worth remembering: http://quotes.cat-v.org/programming/ http://quotes.cat-v.org/programming/ "There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies and the other way is to make it so complicated that there are no obvious deficiencies." — C.A.R. Hoare "The computing scientist's main challenge is not to get confused by the complexities of his own making." — E. W. Dijkstra Most software complexity is of our (programmers) own making.

mistermann 14y ago

You seem to be arguing against consumers insisting Adobe ship defect free software as the cost would be prohibitive, which is true. But that isn't what's being discussed here. What is being discussed: when a defect is discovered in the product by the end consumer, is it a fair (or proper, or wise) business practice to charge the customer for the software patch?

doc4t 14y ago
No I don't think it is alright to charge for a patch. It was not my intention to side track the discussion. I just don't like the simplification of comparing with cars - but the OP made it clear that I misunderstood his post.