This is certainly a good counterpoint to the highly visible silicon valley status quo, but it's risky. Deep thinking might be the solution to a given problem, on the other hand it might give you insight a lot slower than iterating on a prototype. One of the benefits of computers is that experimentation is easier and cheaper than most other technical disciplines, so it's good to be able to whip up some experiments to glean practical information. Arriving at optimal solutions to difficult problems is not an endeavour that is well served by a monolithic approach.
In a way it's the contrapositive of one of my annoyances with TDD. Sometimes TDD advocates (along with anyone selling a methodology I suppose) get overzealous and start making ridiculous claims like "TDD ensures program correctness". When pressed they may backpedal and acknowledge that unit tests are no substitute for mathematical proof. But yet there remains a dogged obsession with one particular technique. Take the experiment of writing a Sudoku solver via strict TDD (http://xprogramming.com/xpmag/OkSudoku). It's obvious that TDD doesn't help you write better algorithms. It's a good discipline for ensuring test coverage, it gives good sanity checks, and it can even help the modularity of your program, but it sure as hell doesn't inherently lead to better code.
So whether you spend years thinking things through before writing a line of code, or most of your time is spent writing and rewriting tests to ensure the perfect coverage, it's always worth reflecting on the effectiveness of time spent and diligently avoid cargo-culting on methodologies.
As a long time device driver and embedded systems programmer, I've found that thinking about the solution only gets you so far. Almost always, intelligent prototyping will make progress quickly. Especially when working with poorly documented hardware, or a system that will never be fully characterized (imagine a complex electromechanical device where the output lags the software commands by many seconds or milliseconds and not in an immediately obvious way), a quick experimental script is often the only way forward.
The biggest downside of experiment based engineering is that if you aren't careful you can easily slip into programming by coincidence rather than intentional engineering. This can lead to unstable systems that nobody understands.
The key question: when new requirements (an inevitability) force you to re-engineer a key element of your system (an inevitability) will you have to perform more "experiments" to figure out which random mutations of your previous design yield the desired results or will you be able to mostly plan ahead of time how to change your design to have the desired characteristics?
If it's the former then you may be faced with the prospect of a change of requirements that you are incapable of coping with, causing your business plan to die. Many software companies have met that fate.
No: I wasn't trying to refute what you wrote. I was pointing out to the reader that though you were arguing that test cases are no replacement for proofs, and were right to argue that, the bugs that test cases catch may overlap with the bugs that a proof will catch, but the former set is not a subset of the latter set.
Comments
This is certainly a good counterpoint to the highly visible silicon valley status quo, but it's risky. Deep thinking might be the solution to a given problem, on the other hand it might give you insight a lot slower than iterating on a prototype. One of the benefits of computers is that experimentation is easier and cheaper than most other technical disciplines, so it's good to be able to whip up some experiments to glean practical information. Arriving at optimal solutions to difficult problems is not an endeavour that is well served by a monolithic approach.
In a way it's the contrapositive of one of my annoyances with TDD. Sometimes TDD advocates (along with anyone selling a methodology I suppose) get overzealous and start making ridiculous claims like "TDD ensures program correctness". When pressed they may backpedal and acknowledge that unit tests are no substitute for mathematical proof. But yet there remains a dogged obsession with one particular technique. Take the experiment of writing a Sudoku solver via strict TDD (http://xprogramming.com/xpmag/OkSudoku). It's obvious that TDD doesn't help you write better algorithms. It's a good discipline for ensuring test coverage, it gives good sanity checks, and it can even help the modularity of your program, but it sure as hell doesn't inherently lead to better code.
So whether you spend years thinking things through before writing a line of code, or most of your time is spent writing and rewriting tests to ensure the perfect coverage, it's always worth reflecting on the effectiveness of time spent and diligently avoid cargo-culting on methodologies.
I have to agree.
As a long time device driver and embedded systems programmer, I've found that thinking about the solution only gets you so far. Almost always, intelligent prototyping will make progress quickly. Especially when working with poorly documented hardware, or a system that will never be fully characterized (imagine a complex electromechanical device where the output lags the software commands by many seconds or milliseconds and not in an immediately obvious way), a quick experimental script is often the only way forward.
The biggest downside of experiment based engineering is that if you aren't careful you can easily slip into programming by coincidence rather than intentional engineering. This can lead to unstable systems that nobody understands.
The key question: when new requirements (an inevitability) force you to re-engineer a key element of your system (an inevitability) will you have to perform more "experiments" to figure out which random mutations of your previous design yield the desired results or will you be able to mostly plan ahead of time how to change your design to have the desired characteristics?
If it's the former then you may be faced with the prospect of a change of requirements that you are incapable of coping with, causing your business plan to die. Many software companies have met that fate.
While very useful, mathematical proofs are not substitutes for unit testing, either.
"Beware of bugs in the above code; I have only proved it correct, not tried it." - Donald Knuth
After that whole thing I wrote, do you really think that's my opinion?
No: I wasn't trying to refute what you wrote. I was pointing out to the reader that though you were arguing that test cases are no replacement for proofs, and were right to argue that, the bugs that test cases catch may overlap with the bugs that a proof will catch, but the former set is not a subset of the latter set.
If I offended your sensibilities, my apologies.