First, let me say that I don't necessarily disagree with you. But, I'm not talking about "design first, code later" mentality. Yes, things can be designed to death, but with the above goals in mind both while you design and while you code (which are really the same step, but that's another Meditation), you can find the balance.

The art of software (design/code/maintanence) is as much about what to leave out, what not to handle, what not to encapsulate, and what not to fix, refine or refactor, as it is about doing those things.

This, to me, falls in the category of Make it clean. Part of being clean means not doing the unneccessary.

Unnecessary security is more than just unecessary--it is a drain on resources, both when coding the program, and when using it.

There is really no such thing as "unnecessary security". It's possible that someone might do something unnecessary in the name of security. But, such things are actually not good security -- the illusion of security reduces security, as does needless complication from unnecessary measures. It's important to remember that the principles above work together -- you can't put all your eggs in making it secure if doing so would cause it not to be clean (or worse, not to work).

Designing in reusability, before there is an application for reuse, besides being a waste of effort if the code is never reused, frequently leads to design and coding descisions that only serve the purpose of the assumed reusability.

There is a big difference between designing-in reusability and coding with reusability in mind. The former, as you've said, is a bad idea unless reusability is one of your goals. However, it is a good idea to avoid practices that needlessly break reusability. Again, by using the principles of "make it work" and "make it clean", it's apparent that there are cases where reusability is less of a concern. That's why I phrased that section the way I did.

Better to code the solution to the problem at hand, and redesign/refactor for reuse

And this is a task made easier by keeping in mind potential reusability during coding. "Oh, I shouldn't make that a constant, what if I need to reuse this?" Of course, sometimes making it work precludes this -- like when performance trumps most other concerns.

I followed dragonchild's earlier link to Extreme Perl--Preface and came across the quoted text below. It (with the addition of a little context) does so much a better job of saying what I was trying to say above, I just wanted to point it out.

Start out by

...do[ing] the simplest thing that could possibly work...

and then--if required--make it (slightly) more complex in order to make it work. Iterate.

I sort of arrived at this basic philosophy for coding (which I attempted to describe in My number 1 tip for developers.), over many years almost by accident. It is basically the result of an adverse reaction to having been forced to attempt to follow one new "programming paradigm", "structured programming methodology" after another as each new fad came (and for the most part went).

From the classical Waterfall Model, through SSADM/LBMS, OOA/OOD, DataFlow Modelling and Use Cases to the current trends for Data Driven and Test Driven development, AOP and XP. Each of these brought something slightly new and valuable to the subject.

The problem is that all too often, that one new thing is seen (by some, temporarially) as the be-all and end-all of chique and they try to design a whole "methodology" around it. The problem for the programmer is pursuading management that whilst that one new pin is a useful technique, that it can be incorporated into the existing working practices without throwing everything else away.

---

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

Very well phrased, if you don't mind me saying so. I think we're in danger of violently agreeing. :)

Yes, new "methodologies" and "shifts in paradigm" arise, shine brightly, and get relegated to the growing pile of Things That Work Just Like Everything Else. What I'm hoping to point out through the parent node is that all of these methods are just approaches to making good software, but the all focus on how rather than what.

I do believe strongly in the iteration style of thought. Programming, like writing, is an iterative process. You brain-dump, then you refine, which might lead to refactors in some cases, which require futher refinement, and so on. Perl has taught me that it isn't how you do something that matters as much as what you accomplish. If one has two approaches to solving a problem and one is faster, cleaner, more secure, etc. -- and it still works -- then that is the better solution. TMTOWTDI, but not all are always the best way.

The whole point of TMTOWTDI, to me, is that each approach has its strengths and weaknesses, and which is "best" to use largely depends on what you're using it for. The "Make it Good" concept is that it doesn't matter what method you choose, so long as you are reaching toward the best balance of Function, Elegance, Security, Ease-of-use (for the target audience), Reusability, and Readability.

Now, I realize that good coding practice can't be relegated to those few short bullet points, but I strongly believe that to use these -- or something like them -- as a framework make a lot more sense than standardizing on the "chic of the week" methodology.

radiantmatrix
require General::Disclaimer;
"Users are evil. All users are evil. Do not trust them. Perl specifically offers the -T switch because it knows users are evil." - japhy

I agree with your first point. Make it work. But I do not think that you gave it enough emphasis (despite putting it first) nor enough importance. It is better to produce something that does something--even if it does it wrong--than to produce nothing at all.

I said produce something. Not produce it and then promote it to the general public.

I did start to try and objectively try and consider whether anything had come out of Matt's script's that might be comsidered good. But then I realised that it would be pointless. Your question has nothing to do with what I said in the post to which you replied. Neither in isolation, nor in the context of the thread of which it is a part.

At this point, I am going to invoke Godwin's Law, as in my opinion, any reference to Matt's script's in the context of Perl programming is exactly equivalent.

---

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

Your question has nothing to do with what I said in the post to which you replied.

Your post caused me to ask myself the question :)

I wasn't trying to subtly argue against you; I think you could make a case either for or against. And the answer to my question applies to your argument taken to the exteme. So if you can decide that the script archive did overall lead to more good than bad, you have a very strong argument in favor of "make it work" over all else.

Yes, I think it was. I learnt perl by fixing bugs in his code. I expect many others did too.