And how do you know the specification is corrrect?
on
When Bad Software Can Kill
·
· Score: 2, Insightful
All that mathematical methods allow you to do is prove that code satisfies a specification. Unfortunately, in most application domains, generating a rigorous specification is not significantly easier or less error-prone than just writing code.
I think it's very sad when CS people fail to notice this obvious fact.
I understand your desire to take vengance on the yuppie, but you might have found knocking him down to be quite difficult. The self-balancing electronics make Segways fiendishly resilient to frontal attack. For future reference, I'd expect a push from the side to be most effective.
Imagine that a chess program is developed that can beat any human opponent. Not such a far-fetched situation.
Now imagine this scenario: Human faces computer in a convention hall. In front of a large crowd, computer resoundingly thrashes human in each match. The computer is surely more intelligent than any human, everyone declares. Then the fire alarm goes off. People run for the exits as the hall fills with smoke and fire. The computer just sits there waiting for its opponent's next move.
Now who's smart?
Yes, business requirements change constantly. That is because the marketplace (that you are so conveniently insulated from in the defense sector) changes constantly. I'm sure that if you can devise a way to freeze the economy in time, your harried neighbours will be delighted to write specifications at their leisure.
No, adding OLE or CORBA support is not refactoring. It's adding new functionality. Refactoring is simplifying code and eliminating redundancies, period.
Even if we accept your improbable claim that good developers always make their code completely clean on the first iteration, it's still the case that multiple developers on the same project often duplicate work. Every large code base I have worked on has had substantial scope for simplification through refactoring.
Slashdot Mirror
All that mathematical methods allow you to do is prove that code satisfies a specification. Unfortunately, in most application domains, generating a rigorous specification is not significantly easier or less error-prone than just writing code.
I think it's very sad when CS people fail to notice this obvious fact.
I understand your desire to take vengance on the yuppie, but you might have found knocking him down to be quite difficult. The self-balancing electronics make Segways fiendishly resilient to frontal attack. For future reference, I'd expect a push from the side to be most effective.
Imagine that a chess program is developed that can beat any human opponent. Not such a far-fetched situation. Now imagine this scenario: Human faces computer in a convention hall. In front of a large crowd, computer resoundingly thrashes human in each match. The computer is surely more intelligent than any human, everyone declares. Then the fire alarm goes off. People run for the exits as the hall fills with smoke and fire. The computer just sits there waiting for its opponent's next move. Now who's smart?
Yes, business requirements change constantly. That is because the marketplace (that you are so conveniently insulated from in the defense sector) changes constantly. I'm sure that if you can devise a way to freeze the economy in time, your harried neighbours will be delighted to write specifications at their leisure.
No, adding OLE or CORBA support is not refactoring. It's adding new functionality. Refactoring is simplifying code and eliminating redundancies, period.
Even if we accept your improbable claim that good developers always make their code completely clean on the first iteration, it's still the case that multiple developers on the same project often duplicate work. Every large code base I have worked on has had substantial scope for simplification through refactoring.