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 :)