Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Comment on

( #3333=superdoc: print w/ replies, xml ) Need Help??

This isn't much of a meditation. More a reference to a couple of pieces of further reading on recent topics prompted by an enquiry.

Testing methodology

Anyone who's been around here for a while (and still bothers to read my posts), will know I have a distaste for Test::* suite of modules. I'm not opposed to testing. Indeed I spent a good part of my career doing pretty much nothing else and am 100% convinced of the need for and value of testing as an integral part of the software development process.

My argument is not about whether you test. It's about what you test. When. And how.

Being a vocal member of a usually silent majority(?), speaking out against practices advocated by the more vocal advocating minority, causes consternation: Why does he think he knows better than all those others?

The answer of course is, I don't. But that doesn't mean I'm wrong either. There is no one right way to do most anything. Some ways work better than others in certain environments; for particular teams or individuals; for particular project types or goals.

Just as getting from A to B may be better accomplished using a car, minivan, pick-up truck, bus, 18-wheeler, train or bike, depending upon the requirements of the journey involved. So RAD, Agile, XP, or waterfall development models will each suite some projects/teams/environments better than others.

If you are a someone who's programming skills are evolving through doing, you start out writing small scripts and debugging by trial and error. As your skills improve and your programs get more complex, you reach a point where you look for a better way. If there are a set of tools and frequent references to those tools and the underlying methodology they implement, you will take a look and give them a go. And if those tools and methodology are an improvement over your previous (non-)practices, you are likely to adopt them and become both practitioner and advocate.

Anything is better than nothing. And if you've only tried one thing, then that thing is going to be the anything that you use. But if you have experienced more than one methodology, whilst you may have an opinion as to which you prefer, it would be a rash man who elected to ignore the alternatives for every project he becomes involved in. Rasher still to recommend it, to the exclusion of all others, for projects that he has only the barest of knowledge of.

There is an old saying:

Good judgement comes from experience, and experience comes from bad judgement.

And I know of no field where that is more applicable than software development.

Best practices

I've also been known to express concerns that a certain set of "Best Practices" has had a detrimental affect upon the way the use of Perl's full syntactic power is perceived. These concerns relate not to the detailing of the best practices themselves, but to their codification as a set of rules enforceable through automation without a full understanding of their implications.

Try as I might, I can come up with no shorter explanation than the following. Drawn from a paper Why Software Quality Assurance Practices Become Evil! (pdf)

(UPDATE: The preceding link doesn't work without registration. However, going to here and clicking the link labelled "View Content Detail:" does))

that I highly commend to all those that see no merit in my apparently contrarian opinions. And those who believe that they are currently using the One True Way of software development and testing. It is only 11 pages, and just might give a few of you pause for thought.

So let me rephrase the title of this paper into a more verbose title: Why requirements management, software design, coding standards, inspections, unit test, integration test, system test, and management reviews become a source of discomfort and repulsion and are offensive. So why is this? Let’s start out by differentiating practices from principles.

Webster’s defines the noun practice to mean “actual performance or application” and uses as an example “ready to carry out practices that they advocated in principle.”

Webster’s defines the noun principle to mean “a comprehensive law, doctrine, or assumption.”

So practicing principles would mean “actual performance or application of a comprehensive law, doctrine, or assumption.”

My actual experience has led me to observe that it is a big mistake for the software industry to focus on the portability of practices from one software project to another. Practices, by their very definition, are specific to their application. We hear things like “best practices,” “standard practices,” “recommended practices,” “common practices,” and (my favorite) “best commercial practices” as if there is a finite set of them, and they work for all situations. Practices are the actions taken to accomplish something.

What if we focused on best principles instead of best practices? A principle is not application specific, therefore it is portable. A single principle can be instantiated into many different practices, each appropriate for specific situations. Principles could be instantiated into appropriate practices based on Risk, for instance.

The pig in a hut

For an explanation of that, you'll have to read the paper above :)


Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.

In reply to Testing methodology, best practices and a pig in a hut. by BrowserUk

Title:
Use:  <p> text here (a paragraph) </p>
and:  <code> code here </code>
to format your post; it's "PerlMonks-approved HTML":



  • Posts are HTML formatted. Put <p> </p> tags around your paragraphs. Put <code> </code> tags around your code and data!
  • Read Where should I post X? if you're not absolutely sure you're posting in the right place.
  • Please read these before you post! —
  • Posts may use any of the Perl Monks Approved HTML tags:
    a, abbr, b, big, blockquote, br, caption, center, col, colgroup, dd, del, div, dl, dt, em, font, h1, h2, h3, h4, h5, h6, hr, i, ins, li, ol, p, pre, readmore, small, span, spoiler, strike, strong, sub, sup, table, tbody, td, tfoot, th, thead, tr, tt, u, ul, wbr
  • Outside of code tags, you may need to use entities for some characters:
            For:     Use:
    & &amp;
    < &lt;
    > &gt;
    [ &#91;
    ] &#93;
  • Link using PerlMonks shortcuts! What shortcuts can I use for linking?
  • See Writeup Formatting Tips and other pages linked from there for more info.
  • Log In?
    Username:
    Password:

    What's my password?
    Create A New User
    Chatterbox?
    and the web crawler heard nothing...

    How do I use this? | Other CB clients
    Other Users?
    Others having an uproarious good time at the Monastery: (6)
    As of 2014-07-26 12:15 GMT
    Sections?
    Information?
    Find Nodes?
    Leftovers?
      Voting Booth?

      My favorite superfluous repetitious redundant duplicative phrase is:









      Results (176 votes), past polls