Comment Re:Beauty for beauty's sake makes crappy software (Score 1) 748
Ever designed a bridge? Do you know how long it takes? Did you know you only get one chance to get it right during the implementation stage?
I think you inadvertantly bring up a good point. Nobody has really figured out yet how long it takes to write flawless code. Hell, by the looks of it, very few companies have even figured out how long it takes to write half-assed code. How often do you hear stories from the software folks like, "Yeah, we finished our project 2 months before our deadline...now we get to sit around and play Quake until it ships."
Think about this, try writing a mathematical proof of a simple program (or mathematical specification, or formal verification--or whatever your favorite software engineering buzz word is--anyway, it's the only way to prove a piece of software is flawless without writing code and testing every possibility)...say a program that outputs the result of multiplying 2 integers together. The proof is straightforward, but is longer than the code needed to implement it.
Now try a bit of code that is only a bit more complicated...say a binary search. Once again, the proof is longer than the code, and it is quite a bit trickier than the proof of the 1st program. Most people in here could hack together a working binary search routine in a short amount of time, but would spend quite a bit more time on the proof that it works flawlessly (if they even [knew how|cared enough] to do it).
Take that analogy and extrapolate it to a large piece of software...any guesses on how long it would take simply to prove all of it's modules work as advertised...let alone the interaction between the modules?
Compare this with how to prove a bridge will not collapse. We've known the basic math behind bridges for thousands of years, and have been applying it for nearly as long (remember, the Romans had bridges). We've been building the more modern bridges since the late 1700s. Only recently can you say that they've perfected them enough that they don't collapse due to a design flaw. Now, yes, we may have known the basic math behind software for nearly as long, but we've only began practicing it this century...we still have a long way to go. Programming as an engineering disipline is still very much in it's infancy.
I think you inadvertantly bring up a good point. Nobody has really figured out yet how long it takes to write flawless code. Hell, by the looks of it, very few companies have even figured out how long it takes to write half-assed code. How often do you hear stories from the software folks like, "Yeah, we finished our project 2 months before our deadline...now we get to sit around and play Quake until it ships."
Think about this, try writing a mathematical proof of a simple program (or mathematical specification, or formal verification--or whatever your favorite software engineering buzz word is--anyway, it's the only way to prove a piece of software is flawless without writing code and testing every possibility)...say a program that outputs the result of multiplying 2 integers together. The proof is straightforward, but is longer than the code needed to implement it.
Now try a bit of code that is only a bit more complicated...say a binary search. Once again, the proof is longer than the code, and it is quite a bit trickier than the proof of the 1st program. Most people in here could hack together a working binary search routine in a short amount of time, but would spend quite a bit more time on the proof that it works flawlessly (if they even [knew how|cared enough] to do it).
Take that analogy and extrapolate it to a large piece of software...any guesses on how long it would take simply to prove all of it's modules work as advertised...let alone the interaction between the modules?
Compare this with how to prove a bridge will not collapse. We've known the basic math behind bridges for thousands of years, and have been applying it for nearly as long (remember, the Romans had bridges). We've been building the more modern bridges since the late 1700s. Only recently can you say that they've perfected them enough that they don't collapse due to a design flaw. Now, yes, we may have known the basic math behind software for nearly as long, but we've only began practicing it this century...we still have a long way to go. Programming as an engineering disipline is still very much in it's infancy.
