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/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
This post was sourced from https://writers.stackexchange.com/q/5752. It is licensed under CC BY-SA 3.0.
2 answers
You are accessing this answer with a direct link, so it's being shown above all other answers regardless of its score. You can return to the normal view.
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.
This post was sourced from https://writers.stackexchange.com/a/5758. It is licensed under CC BY-SA 3.0.
0 comment threads
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 comment threads
0 comment threads