Communities

Writing
Writing
Codidact Meta
Codidact Meta
The Great Outdoors
The Great Outdoors
Photography & Video
Photography & Video
Scientific Speculation
Scientific Speculation
Cooking
Cooking
Electrical Engineering
Electrical Engineering
Judaism
Judaism
Languages & Linguistics
Languages & Linguistics
Software Development
Software Development
Mathematics
Mathematics
Christianity
Christianity
Code Golf
Code Golf
Music
Music
Physics
Physics
Linux Systems
Linux Systems
Power Users
Power Users
Tabletop RPGs
Tabletop RPGs
Community Proposals
Community Proposals
tag:snake search within a tag
answers:0 unanswered questions
user:xxxx search by author id
score:0.5 posts with 0.5+ score
"snake oil" exact phrase
votes:4 posts with 4+ votes
created:<1w created < 1 week ago
post_type:xxxx type of post
Search help
Notifications
Mark all as read See all your notifications »
Q&A

Post History

50%
+0 −0
Q&A 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 social proof that trendy tools/techni...

2 answers  ·  posted 12y ago by dukeofgaming‭  ·  last activity 5y ago by System‭

#3: Attribution notice added by user avatar System‭ · 2019-12-08T02:23:42Z (almost 5 years ago)
Source: https://writers.stackexchange.com/q/5752
License name: CC BY-SA 3.0
License URL: https://creativecommons.org/licenses/by-sa/3.0/
#2: Initial revision by user avatar dukeofgaming‭ · 2019-12-08T02:23:42Z (almost 5 years ago)
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](http://en.wikipedia.org/wiki/Social_proof) that trendy tools/techniques are not necessarily [cargo cult](http://en.wikipedia.org/wiki/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](http://en.wikipedia.org/wiki/Distributed_revision_control) (Distributed Version Control) and [TDD](http://en.wikipedia.org/wiki/Test-driven_development) (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](http://en.wikipedia.org/wiki/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](http://www.joelonsoftware.com/items/2007/11/16.html) 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

#1: Imported from external source by user avatar System‭ · 2012-05-24T17:29:09Z (over 12 years ago)
Original score: 6