How to leverage social proof?

Question

How can one use social proof as an argument without sounding like "just because everybody is doing it so should you"?. My problem is trying to demonstrate with social proof that trendy tools/techniques are not necessarily cargo cult

I'm writing a whitepaper regarding best-practices and new tools in the industry of software engineering. There are certain controversial topics like DVCS (Distributed Version Control) and TDD (Test-Driven Development) that do work, but require changing mindsets and extra effort at the beginning to reap the rewards. Something along the lines of this:

More and more developers are being converted into DVCSs because of its success in
overcoming classical frustrations in CVCSs, such as avoiding merging hell and commit
races. Adoption involves evolving the centralized mindset as DVCSs change the 
paradigm of version control, after developers accept the new paradigm and embrace 
it —which generally involves trying to go back to the centralized mindset— they will
start reaping the benefits and become increasingly aware of how scalable this 
paradigm is in terms of collaboration.

Even if the previous paragraph sounds credible, I don't think people resistant to change will see another thing from "oh, it's cargo-cult". I think social proof is relevant to this case (as adoption is important to the enterprise due to support professional support markets & well-tested environments), but cannot help to think that this could get on the bad side of rhetoric (too much pathos?).

Since those kinds of things are being increasingly adopted and preached, how could one turn this situation as a good convincing argument?. I was reading Joel's entry on demonstrating software and social proof but it seems like a double-edged sword.

Additional context: VCS or Version Control Systems are (in a nutshell) programs that let you store incremental differences (or changes/deltas) to text files so that then you can rebuild them at a particular point later; these systems are mostly use for writing software.

There are currently two models: a) the centralized one (CVCS) where each user to be hooked up to a server to use these systems, making them slower and bottlenecking collaboration, as everyone needs to stand in line to store the changes to this sole "code bucket", and b) the distributed model (DVCS) where each programmer has their own "bucket", so there is no need for a server, everyone puts their work on their own "bucket".

The important thing in DVCSs and collaboration happens after, until they have finished and refined work to share and be proud about instead of stepping on each other's toes with incomplete work (and still being able to rely on version control to aid their own work). In a DVCS each peer can check each other's buckets and they can add their bucket's contents to others' too.

P.S.: Sorry for the wall of text

Answer 1

If I'm understanding you correctly, I think what you want are case studies to demonstrate your points.

So you put forth one of your arguments — "switching to the individual bucket version reduces problems A, B, and C" — and then you put in a section with an actual real-life example:

---

Case Study: Acme Widget Coders Amalgamated

AWCA had been using centralized bucketing for many years, but it was causing production bottlenecks whenever the buckets were all dumped into the same coding trough at the end of a widgeting session. Switching over to individual buckets was a huge boost to efficiency. Programmers had more flexibility, errors were caught much earlier in the process, and there were fewer holes in the buckets, dear Liza, dear Liza.

---

If you do this for each facet of your argument (or each problem which your trendy technique purports to solve), then your reader will see that you're not just lusting after the latest sparkly vampire of coding solutions, but rather presenting something which is useful and has been field-tested to produce significant results.

Answer 2

The key is to establish a strong foundation first. Someone who is resistant to change will need to see why change is necessary, how it can be accomplished easily and cheaply, and then feel the pressure of "all the cool kids are doing it."

If you don't establish the reason why change must happen, then social proof will look like flash-in-the-pan.

I would suggest first demonstrating the advantages of the new over the old, and then the benefits of adopting the new practice which comes at the modest expense of a tiny little paradigm shift.

Once you've established a sensible and strong argument for the adoption of the new practice, then you can leverage social proof as additional support.

CVCS has been the standard since it became necessary to do something other than copy material to a dated folder in the "Backup" file. However, methods of software production have changed since CVCS was introduced 20 years ago, resulting in performance bottlenecks and cranky people wasting time on the nets while waiting for their code to be ready. DVCSs solves the classical frustrations of CVCSs, such as avoiding merging hell and commit races. The adoption of DVCS creates a versioning environment that is more natural for workers, resulting in geometrically increased productivity and infinitely scalable cooperativity. Training workers to use the new format takes less than a week, and once adopted, it quickly becomes intuitive. They can version in their sleep.

Many sensible, knowledgeable, and successful people have already recognized the genius of this plan. They shag frequently with beautiful, famous, and wealthy people. We recommend you adopt this practice as well, since everyone will be doing it in the future.

What you want to do is establish why this is a good practice, how it can be adopted especially by people who are familiar with the old practice, and then give a little peer pressure. That way, the reader will feel more like they will be on the cutting edge rather than just jumping on the bandwagon.

Answer 3

I think I've found another way to leverage social proof as such: the hype cycle. Pasting from Wikipedia:

• "Technology Trigger" — The first phase of a hype cycle is the "technology trigger" or breakthrough, product launch or other event that generates significant press and interest.
• "Peak of Inflated Expectations" — In the next phase, a frenzy of publicity typically generates over-enthusiasm and unrealistic expectations. There may be some successful applications of a technology, but there are typically more failures.
• "Trough of Disillusionment" — Technologies enter the "trough of disillusionment" because they fail to meet expectations and quickly become unfashionable. Consequently, the press usually abandons the topic and the technology.
• "Slope of Enlightenment" — Although the press may have stopped covering the technology, some businesses continue through the "slope of enlightenment" and experiment to understand the benefits and practical application of the technology.
• "Plateau of Productivity" — A technology reaches the "plateau of productivity" as the benefits of it become widely demonstrated and accepted. The technology becomes increasingly stable and evolves in second and third generations. The final height of the plateau varies according to whether the technology is broadly applicable or benefits only a niche market.

The 5th stage called the plateau of productivity can demonstrate (to a certain degree; it can be deemed unscientific) that a technology has become mature and stable.

This could be partly demonstrated with Google Insights for search and the correct search terms:

dvcs +distributed +git +mercurial -nike -"mercurial vapor" -FIFA
scm +distributed +git + mercurial -nike -"mercurial vapor" -FIFA

(Should give them more tries, as these are biased)

In the paper I think I can give historical proof of each phase and as such give an historical overview of version control systems. For the plateau of productivity I can use the case studies Lauren Ipsum suggested.