3 ms·

What a load of tosh. What is this, the "if it's not on the web, it's not real code" party? Show me an embedded system codebase that any of the duct tape people

What a load of tosh. What is this, the "if it's not on the web, it's not real code" party? Show me an embedded system codebase that any of the duct tape people have put together, systems where failures kill people, and tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system. Bugs in systems like that will kill people, and we're getting to a state these days where those systems are becoming more and more embedded in day to day life and the risk to Joe Soap is getting higher. How long until a bad UI in a GPS iPhone app turns out to be a contributing factor in a bad car accident? Or until a web-based medical app with a hidden bug screws up a dosing calculation for a patient? This whole duct-tape-it-and-ship-the-sucker mentality has got to stop, before someone gets badly hurt.

plinkplonk 17y ago
"Show me an embedded system codebase that any of the duct tape people have put together," StrawMan. replace "duct tape programmers" by "TDD/Agile consultants" What do you get? ;-) "tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system." More Strawmen. Would you be happier if methodology consultants whose only programming experience in the last 10 years was working on a PayRoll System at Chrysler (which failed btw) used TDD to develop your chemotherapy/fly-by-wire/ABS brakes? ;-)
- markdennehy 17y ago
  Are you asking if I would be happier if there was testing done on my ABS brakes/chemotherapy/fly-by-wire software than if there wasn't? Seriously? You're suggesting there's an alternative? Or are you saying you base your level of happiness on the experience level of the coders involved rather than their test coverage stats? Because last I checked, experience levels meant very little. The Tacoma Narrows bridge was designed by - at the time - the foremost structural engineers in the world. Their paper on its design was recognised as the single most important paper of its kind in that decade. The bridge still fell, not because they were wrong, but because of something nobody had encountered yet (in this case, aerodynamic flutter). Critical code is precisely that - critical. You don't leave it to the "gifted engineer" model of development because that always fails. Noone is gifted and diligent 100% of the time, everyone screws up eventually. It's dangerously arrogant to think otherwise. You build a system of work that lowers the probability that those screwups make it into a working system, that's all. Civil and Mech. and other engineering branches have been doing it for decades. We're just getting started on it in this branch of engineering.
  - eugenejen 17y ago
    You can not write tests that test/discover defects that you don't know as defects. The Tacoma Bridge case proves exactly the above statement. If we all can conceive tests that remove all defects from past, now and future, then we all live perfect lives. But that is impossible, though we can try to minimize the impact. The problem is probably is undecidable in computational complexity sense. And to some point, we need people, maybe our beloved one, maybe ourselves to be sacrificed in order for scientists and engineers in the next generation to figure out and put them into their test cases to avoid repetition of tragedies. I think you misunderstand gifted engineers. Gifted engineers understand what they shipped are imperfect, but they have guts to ship them and see how they work. The failure will be lessons for next generation to learn. I feel more scared of people who think their tests have removed all known defects while they forget about unknown defects. They have committed the sin of "confirmation bias" and is much worse to welfare of humanity.
    - deleted 17y ago
      [deleted]
    - markdennehy 17y ago
      You say "guts to ship and see", I say "piss-poor engineering at best, unethical criminal negligence at worst"...
      - eugenejen 17y ago
        There are part of computer science and engineering dealing with well defined problems. then it is easier to judge solutions to problems by proofs and test cases. Whoever can't prove their code is right or writing test cases are really criminal in their professions. But there are another part of computer science and engineering dealing with fuzzy requirements or unknown problems. I don't see any better way to explore that area except trials and errors and the scientists and engineers have to face possible charges of "piss-poor", unethical, criminal and evil for the consequences of their solutions. I feel that you have a very clear dichotomy of moral system. Unfortunately I deal with fuzzy things daily and see the harms of dichotomy in creating new stuffs and burning through money without any fruit of labor. It is easy for you to improve existing technologies because you can define criteria for improvements. But it is so hard in underfunding web startups that you can't expect in advance what a new solutions will be to users unless you make it and test it with them. If I need someone to preserve and maintain existing software systems, because specifications and use cases are well defined, people like you are well fit for the task. But if someone has a new idea to solve a new problem that no one solved before, I would rather to see an unsophisticated solution first to test against the problem and start from there, and I am ready to rewrite the system when the problem becomes clearer.

plinkplonk 17y ago

"Show me an embedded system codebase that any of the duct tape people have put together," StrawMan. replace "duct tape programmers" by "TDD/Agile consultants" What do you get? ;-) "tell me you'd be happy depending on those systems, for your chemotherapy or your ABS brakes or your ATM code or your airliner's fly-by-wire system." More Strawmen. Would you be happier if methodology consultants whose only programming experience in the last 10 years was working on a PayRoll System at Chrysler (which failed btw) used TDD to develop your chemotherapy/fly-by-wire/ABS brakes? ;-)

markdennehy 17y ago
Are you asking if I would be happier if there was testing done on my ABS brakes/chemotherapy/fly-by-wire software than if there wasn't? Seriously? You're suggesting there's an alternative? Or are you saying you base your level of happiness on the experience level of the coders involved rather than their test coverage stats? Because last I checked, experience levels meant very little. The Tacoma Narrows bridge was designed by - at the time - the foremost structural engineers in the world. Their paper on its design was recognised as the single most important paper of its kind in that decade. The bridge still fell, not because they were wrong, but because of something nobody had encountered yet (in this case, aerodynamic flutter). Critical code is precisely that - critical. You don't leave it to the "gifted engineer" model of development because that always fails. Noone is gifted and diligent 100% of the time, everyone screws up eventually. It's dangerously arrogant to think otherwise. You build a system of work that lowers the probability that those screwups make it into a working system, that's all. Civil and Mech. and other engineering branches have been doing it for decades. We're just getting started on it in this branch of engineering.
- eugenejen 17y ago
  You can not write tests that test/discover defects that you don't know as defects. The Tacoma Bridge case proves exactly the above statement. If we all can conceive tests that remove all defects from past, now and future, then we all live perfect lives. But that is impossible, though we can try to minimize the impact. The problem is probably is undecidable in computational complexity sense. And to some point, we need people, maybe our beloved one, maybe ourselves to be sacrificed in order for scientists and engineers in the next generation to figure out and put them into their test cases to avoid repetition of tragedies. I think you misunderstand gifted engineers. Gifted engineers understand what they shipped are imperfect, but they have guts to ship them and see how they work. The failure will be lessons for next generation to learn. I feel more scared of people who think their tests have removed all known defects while they forget about unknown defects. They have committed the sin of "confirmation bias" and is much worse to welfare of humanity.
  - deleted 17y ago
    [deleted]
  - markdennehy 17y ago
    You say "guts to ship and see", I say "piss-poor engineering at best, unethical criminal negligence at worst"...
    - eugenejen 17y ago
      There are part of computer science and engineering dealing with well defined problems. then it is easier to judge solutions to problems by proofs and test cases. Whoever can't prove their code is right or writing test cases are really criminal in their professions. But there are another part of computer science and engineering dealing with fuzzy requirements or unknown problems. I don't see any better way to explore that area except trials and errors and the scientists and engineers have to face possible charges of "piss-poor", unethical, criminal and evil for the consequences of their solutions. I feel that you have a very clear dichotomy of moral system. Unfortunately I deal with fuzzy things daily and see the harms of dichotomy in creating new stuffs and burning through money without any fruit of labor. It is easy for you to improve existing technologies because you can define criteria for improvements. But it is so hard in underfunding web startups that you can't expect in advance what a new solutions will be to users unless you make it and test it with them. If I need someone to preserve and maintain existing software systems, because specifications and use cases are well defined, people like you are well fit for the task. But if someone has a new idea to solve a new problem that no one solved before, I would rather to see an unsophisticated solution first to test against the problem and start from there, and I am ready to rewrite the system when the problem becomes clearer.