Thoughts On ...

I use the term to explain how I perceive source code control, and why I use it. I don't use it because it's ever paid off in any significant way for me, but I accept that people who are smarter than I have found it to be good in an insurancy kind of a way. I understand its benefits and I could enumerate them, but since I haven't experienced them I prefer to say, "hey, I'm just relying on expert industry consensus here," and leave it at that. For me, that's what "best practice" means and why I'm happy to keep using it.

Several thoughts came to mind when I read your comment Carl (and thanks for posting btw):

1) Are you saying you don't find/understand the benefits and tradeoffs, and so simply do it because of industry consensus, or are you saying that this is how you justify it to skeptics?

2) Even something as ubiquitous as using source code control tools has a context -- and alternatives. E.g. I worked in a small shop that didn't use any SCM tool, and successfully delivered many versions of their software (whether the should or not, isn't the point).

2) Saying "hey its a best practice" -- without any other justification is an ad populum fallacious argument (http://www.intrepidsoftware.com/fallacy/pop.php) -- as people who work with applied logic for a living, we can do better.

3) My advocacy of *not* using the term -- and my admonition against evangelism -- was itself evangelism, and should be treated accordingly. I.e. if it works for you, go for it.

> 1) Are you saying you don't find/understand

> the benefits and tradeoffs, and so simply do

> it because of industry consensus, or are you

> saying that this is how you justify it to

> skeptics?

I can get excited, enthusiastic, about certain practices - TDD for one - because of direct personal experience of their benefits. Other practices - like SCM - I believe I should be following because they make sense even though the payoff experience hasn't been there for me.

For the practices I enthuse about, I can make concrete experiential arguments; for the others I can make theoretical arguments, but I feel honor-bound to qualify every statement: "but it's never yet paid off for me". Maybe it is lazy of me to avoid such lengthy, wishy-washy arguments, but "best practices" seems like a useful shorthand. Bottom line is, I do it, and my basis for choosing to do so lies in the experience and analysis of other people, qualified by my judgement of their arguments.

Maybe that's fallacious, but it feels right to me, and I like the efficiency of the rationale. It doesn't mean, to me, "everyone should always do this;" it means rather that I choose to and I don't have a strong, direct, personal reason for it - but the reason I have is sufficient for me.

Which doesn't really answer your question. I understand the benefits and tradeoffs; I haven't experienced the benefits, but I believe that someday I may. It's not just how I justify it to skeptics, but is a good shorthand for my real underlying reason for using the practice.

> 3) My advocacy of *not* using the term -- and

> my admonition against evangelism -- was itself

> evangelism, and should be treated accordingly.

> I.e. if it works for you, go for it.

Sounds good to me. I didn't think you were pushing me (or us all) too hard to adopt your approach, and I'm certainly not pushing you to adopt mine - just explaining why I've got a different slant on it.