: How to leverage social proof? 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

Vote Up Vote Down

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.

(0)

Vote Up Vote Down

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.

(0)

Vote Up Vote Down

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.

(0)