It's a fair enough question of it's own right, but I don't see the the mistake was in his writing the scripts.
The mistake was in his promoting their use to the general public, and continuing to promote them even after the flaws were well known and documented and had been brought to his attention.
That's a different issue entirely to that which I was trying to address. My point was that it is better to have an attempt at a solution to a specified problem as quickly as possible. Correct or incorrect, having something to test is better than having a theoretical design and no code.
It's essentially the Rapid Prototyping-Extreme Programming philosophy of starting simple and small and fast and then exercising the code to discover it's flaws, limitations and misassumptions. It's very hard, and usually counter-productive to try to design something for the first time. That is to say, without knowing the problems one will encounter, you can expend an aweful lot of energy catering for situations that will never arise in practice. And in doing so, it is easy to miss the those problems that will occur.
Silly example. There were, in hindsight, some pretty silly design criteria and decisions made in the '50s by aerospace engineers trying to design a supersonic aircraft. The were a lot of scare stories about what would happen to an aircraft when it reached the sound barrier. And a lot of energy expended trying to counter them.
The world now builds and flies supersonic aircraft routinely. What allows this to be so routine in large part was the work done on the X-1 and X-86. Prototypes that were dangerous and could never have been usable as production craft, but it was through them, the ground they covered, and the fud that they eliminated or raised to the status of real problems, that allowed the F105B, and all subsequent production supersonics to be built.
Taking the philosophy that every program must be secure, user friendly, reusable is (IMO) untenable. It's somewhat akin to making every script you write totally portable for the off chance that one day you may want to port it. Better to wait until you need to port it, then make it portable.
This doesn't mean that you leave a script that needs to be secure, unsecured. It means that you don't expend effort making scripts that don't need to be secured, secure.
It doesn't mean that when writing a script, that if you see a simple way of making some part of it reusable that doesn't compromise the known application of it, that you don't take that route. It means that unless you know up front that a piece of code is likely to be reused, you don't expend additional effort to make it reusable.
Doing so without cause
- can compromise the project in terms of budget, functionality or time.
- often as not, when the time comes to reused the code, the efforts made will not have been completely successful anyway, which means that the code will need to be modified for the new use.
That, in turn often means modifying the original code in order to mainatain the common codebase anyway.
So, it is better to leave all the modifications required to allow reuse until you a) know that it is going to be reused. b) know how it is going to be reused.
Only then can the changes required be accessed in light of full knowledge of thr requirements. And the occasion may never arise anyway.
I don't disagree with radiantmatrix that keeping security, reuse etc. "in mind" when designing or coding programs is a bad thing. Indeed, I would add efficiency (both memory and cycles) to the list.
In the end, it all a case of emphasis and balance.
Examine what is said, not who speaks.
"Efficiency is intelligent laziness." -David Dunham
"Think for yourself!" - Abigail
"Memory, processor, disk in that order on the hardware side. Algorithm, algorithm, algorithm on the code side." - tachyon
