Re^3: Make it good

[BrowserUk]

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.

[radiantmatrix]

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.