• Justin (unregistered)

    TRWTF isn't that the steel mill owner's son got to run an (I imagine very expensive) R&D lab with a good sized staff and payroll, and never produced anything? Ah well, I guess if you make a lot of money, you're allowed to do what you want with the profits, including keeping your son busy so he won't go near the production equipment

    captcha: persto (only one letter away from Pesto, which I've only occasionally not hated in cooking)

  • Suscipit (unregistered) in reply to frits
    frits:
    An Onimizer:
    justsomedude:
    In theory there is no difference between practice and theory, but in practice there sure as hell is!

    Oh dear. I'm so totally fed up with this little gem of wisdom.

    When someone quotes it to me after a WTF, it usually turns out that

    • cowboy mode was applied instead of any theory at all

    • the wrong theory was applied

    • the correct theory was applied incorrectly, e.g. due to insufficient understanding of the theory

    I have yet to meet the case where the theory was insufficiently advanced to solve the problem - in which case you should work on the theory before you try a solution.

    The above adage is just a poor attempt at being witty after having botched it, usually by people with an attitude of "Theory? We're doing real work here!" As if computers in a university and computers in an office were somehow different. The first people to make a magnetic drum memory, for example, weren't cowboys but professors, and without them the fabled garage companies wouldn't have happened, period.

    You win the dum-dum prize. The inventor of magnetic drum memory was an engineer and businessman: http://en.wikipedia.org/wiki/Gustav_Tauschek

    Many inventions come from industry and goverment research, not professors. See "Bell Labs". If theory were sufficient, why have theorectical and experimental physisists? Surely there is no need to test all these wonderful theories. In fact, theory only comes after making careful observations, not before.

    Of course theory comes after. However, there are way too many coders out there who think that every problem is original, has never been solved before and needs thousands of lines in their favorite language to be half solved. They're the ones who spread that they need no stinkin theory, creating a dozen new problems in their wake for every half-baked solution they create. Well, at least they contribute to job security until the company folds. Programming failures are now estimated to cost in the trillions of dollars.

    So get a clue before you start.

  • Spudd86 (unregistered) in reply to arty
    arty:
    Seminymous Coward:
    Seriously, y'all are going to unanimously go with "proofs are stupid?" A real proof is a guarantee of correctness. TRWTF is abuse of the word "proof." Even an idiot can say they have a proof.

    Unfortunately, mathematics can't prove much about about complicated programs in unrestricted turing machines.

    Why don't we have standard support for making objects into communicating sequential processes in the standard library of any language? Why don't we have a finite automaton other than regex(3) in the standard library?

    Err... you can prove pretty much anything that is true about a program, finding the proof is the tricky bit.

    Luckily people can write there code in a clear straightforward manner than makes proving things about it easier (like 'the following loop invariant is maintained thus at the end of the loop we have X, this implies the next bit results in Y which is our desired result' and such). Yes, proving correctness is not easy, but doing it means you WILL find lots of errors that are hard to test for and you are forced to document your assumptions (so that if the assumptions your codes correctness and your proof rest on are false your fellow developers can point this out)

    If reliability is REALLY important you should do both testing and proofs of correctness, then follow that up with code mandatory reviews, to really flush out the assumptions and check the proof and tests and the code itself to make sure that they match each other and the rest of the program.

  • eric bloedow (unregistered)

    somehow, the comments made me think of the infamous "sergeant York" automated weapon platform. it was first supposed to shoot down anti-tank missiles aimed at friendly tanks. it worked perfectly in simulations, but when put to a practical test, it ignored the missiles and shot at trees! so they they tried to re-program it to shoot down enemy helicopters instead. they thought the whirling blades on top would be simple enough for the program to to recognize. again, it worked in simulation, but when tested...it ignored the helicopter and blew a ventilator fan on the roof of a building! and on top of that, it couldn't keep up with the tanks it was supposed to protect...

  • markm (unregistered)

    The first time I heard about "proven correctness", I immediately thought, "Maybe you can prove it does what you think it should, but you can't know it does what the customer really wanted until he tries it."

    My experience in hardware as well as software is that the customer never knows what he wants with sufficient precision, so the specs are always wrong. You should get to a prototype that the customer can sit down and try ASAP, then it's possible to refine the specs and finish the design.

Leave a comment on “The Proven Fix”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article