Cunningham’s Law
วิธีได้คำตอบที่ถูกบนอินเทอร์เน็ต ไม่ใช่การถาม แต่คือการ post คำตอบผิด ๆ
Cunningham’s Law (ตั้งชื่อตาม Ward Cunningham ผู้คิดค้น wiki) กล่าวว่า:
“วิธีที่ดีที่สุดในการได้คำตอบที่ถูกต้องบนอินเทอร์เน็ต ไม่ใช่การตั้งคำถาม แต่คือการ post คำตอบที่ผิด”
— เชื่อว่ามาจาก Ward Cunningham
ใจความสำคัญ
หัวข้อที่มีชื่อว่า “ใจความสำคัญ”กฎนี้ไม่ได้มาจากบทความวิชาการหรือหนังสือ แต่มาจากคำให้การกึ่งเกร็ดประวัติศาสตร์ Steven McGeady อดีตผู้บริหารของ Intel เล่าไว้ในคอมเมนต์บน block ภาษาศาสตร์ของ New York Times เมื่อปี 2010 ว่า Ward Cunningham เคยแนะนำเทคนิคนี้ให้เขาฟังตอนทำงานร่วมกันที่ Tektronix ในช่วงต้นทศวรรษ 1980 สำหรับใช้ดึงข้อมูลจากกระดานสนทนา USENET McGeady จึงตั้งชื่อมันว่า “Cunningham’s Law” เพื่อเป็นเกียรติ
ที่น่าสนใจคือ Ward Cunningham เองปฏิเสธว่าไม่เคยพูดแบบนั้น เขาเรียกกฎนี้ว่าเป็น “คำพูดที่ถูกยกผิด ๆ ซึ่งพิสูจน์ตัวเองด้วยการแพร่กระจายไปทั่วอินเทอร์เน็ต” (a misquote that disproves itself by propagating through the internet) และย้ำว่า “ผมไม่เคยแนะนำให้ถามคำถามด้วยการ post คำตอบผิด” กล่าวคือ ตัวกฎเองก็เป็นตัวอย่างของปรากฏการณ์ที่มันบรรยาย — เรื่องเล่าที่ผิดเพี้ยนจากปากต่อปาก (หรือกระดานต่อกระดาน) จนกลายเป็น “ความจริง” ที่ทุกคนอ้างอิง ไม่ต่างจากคำตอบผิด ๆ ที่ถูกแก้ไขจนกลายเป็นคำตอบที่ถูก
ไม่ว่าที่มาจะกำกวมแค่ไหน ปรากฏการณ์ที่กฎนี้บรรยายนั้นสังเกตได้จริงและสังเกตซ้ำได้ในชุมชนออนไลน์แทบทุกแห่ง: คำถามที่เปิดกว้างมักถูกเมิน เพราะการตอบต้องใช้ความพยายามและความเมตตาจากผู้อื่น แต่ข้อความที่ยืนยันบางอย่าง “อย่างมั่นใจแต่ผิด” มักกระตุ้นอารมณ์อยากแก้ไขของคนที่รู้จริง จนพวกเขาอดไม่ได้ที่จะเข้ามาชี้แจงทันที — Wikipedia เองก็ถูกยกเป็นตัวอย่างพิสูจน์กฎนี้ที่โด่งดังที่สุด เพราะบทความจำนวนมากเริ่มจากฉบับร่างที่ไม่สมบูรณ์หรือผิดพลาด แล้วถูกชุมชนช่วยกันแก้จนแม่นยำขึ้นเรื่อย ๆ
ความหมายและนัยยะ
หัวข้อที่มีชื่อว่า “ความหมายและนัยยะ”กลไกทางจิตวิทยาเบื้องหลังกฎนี้อาศัยความไม่สมมาตรระหว่างสองพฤติกรรมทางสังคม:
- การตอบคำถาม เป็นการกระทำเชิงรุกที่ต้องใช้ความเสียสละ — ต้องคิดเอง ไม่มีอะไรผูกมัดให้ต้องตอบ และถ้าตอบผิดก็เสี่ยงถูกตำหนิ คนจำนวนมากจึงเลือก “เงียบ” มากกว่าเสี่ยง
- การแก้ไขคำตอบที่ผิด เป็นการกระทำเชิงรับที่มีต้นทุนต่ำกว่ามาก — มีโจทย์ตั้งต้นให้ค้านอยู่แล้ว ผู้แก้ไม่ต้องเริ่มจากศูนย์ แค่ชี้จุดผิดก็พอ และการชี้ผิดคนอื่นมักให้ความรู้สึกพึงพอใจทางอัตตา (ego) มากกว่าการตอบคำถามเฉย ๆ
พูดอีกแบบ กฎนี้ไม่ได้บอกว่าการโกหกเป็นกลยุทธ์ที่ดี แต่ชี้ให้เห็นว่า สิ่งกระตุ้นที่เป็นรูปธรรม (a concrete, falsifiable claim) มีพลังดึงดูดการมีส่วนร่วมมากกว่าคำถามที่เปิดกว้าง หลักการเดียวกันนี้ถูกนำไปเปรียบกับสำนวนฝรั่งเศส “prêcher le faux pour savoir le vrai” (เทศนาความเท็จเพื่อให้รู้ความจริง) และเทคนิคการสืบสวนสอบสวนแบบ Sherlock Holmes ที่บางครั้งตั้งสมมติฐานผิด ๆ ขึ้นมาล่อให้ผู้ต้องสงสัยเผยตัว
ในบริบทวิศวกรรมซอฟต์แวร์ กฎนี้อธิบายว่าทำไม pull request ฉบับร่างที่ยังไม่สมบูรณ์ถึงมักได้ feedback เร็วและละเอียดกว่าการไป post ถามในแชนแนลทีมว่า “ควรออกแบบยังไงดี” — เพราะ code ที่จับต้องได้คือ “คำตอบที่ตรวจสอบได้” ให้คนอื่นเข้ามาแก้ ในขณะที่คำถามลอย ๆ ไม่มีอะไรให้ค้าน
ตัวอย่างในโลกจริง
หัวข้อที่มีชื่อว่า “ตัวอย่างในโลกจริง”- Stack Overflow / กระดานสนทนาเทคนิค ผู้ใช้จำนวนไม่น้อยพบว่าการ post “ผมลองทำแบบนี้ ผลลัพธ์คือ X” (แม้จะยังไม่ถูกทั้งหมด) ได้รับความคิดเห็นแก้ไขเร็วกว่าการ post คำถามเปล่า ๆ ว่า “ทำยังไง”
- Wikipedia เป็นตัวอย่างที่ McGeady เองยกไว้อย่างชัดเจนว่าเป็นการพิสูจน์กฎนี้ในระดับสถาบัน — บทความฉบับร่างที่ไม่สมบูรณ์กระตุ้นให้อาสาสมัครเข้ามาแก้ไขต่อเนื่อง จนระบบทั้งระบบทำงานเหมือน “เครื่องจักรแก้ไขคำตอบผิด” ขนาดใหญ่
- การ code review ในทีม วิศวกรรุ่นน้องที่ส่ง draft PR ที่ยังไม่สมบูรณ์ มักได้ข้อเสนอแนะที่เจาะจงและนำไปใช้ได้จริงจากรุ่นพี่ มากกว่าการไปถามคำถามกว้าง ๆ ว่า “ควรออกแบบ module นี้ยังไง” เพราะ code ที่เขียนไว้แล้วให้ “เป้า” ที่จับต้องได้ให้คนอื่นวิจารณ์
- RFC / design doc ภายในทีม วิศวกรอาวุโสหลายคนตั้งใจเขียนข้อเสนอฉบับแรกให้มีจุดที่ยังถกเถียงได้ (แทนที่จะทิ้งเป็นคำถามเปิด) เพราะรู้ว่าข้อเสนอที่เป็นรูปธรรมจะดึงความเห็นแย้งที่มีคุณภาพออกมาได้เร็วกว่า
- การ debug ต่อหน้าเพื่อนร่วมทีม เวลาบอกเพื่อนว่า “bug นี้เกิดจาก race condition ใน queue แน่ ๆ” (ทั้งที่ยังไม่แน่ใจ) มักกระตุ้นให้เพื่อนรีบชี้ว่า “ไม่ใช่ ดูตรงนี้สิ” เร็วกว่าการถามลอย ๆ ว่า “ทำไมมันพังนะ”
บทเรียนที่นำไปใช้
หัวข้อที่มีชื่อว่า “บทเรียนที่นำไปใช้”- ใช้แบบมีจริยธรรม ไม่ใช่ใช้เพื่อหลอกลวง เจตนาของเทคนิคนี้ไม่ใช่การจงใจ post ข้อมูลเท็จเพื่อบงการคนอื่น แต่คือการนำเสนอสมมติฐานหรือคำตอบที่ดีที่สุดเท่าที่ทำได้ ณ ตอนนั้น (best-effort answer) แล้วเปิดให้แก้ไข ความแตกต่างสำคัญคือ “ความตั้งใจ” — สื่อสารตรง ๆ ว่านี่คือความเข้าใจปัจจุบัน ไม่ใช่คำตอบที่ยืนยันแน่นอน
- เมื่อทีมเงียบใส่คำถามเปิด ให้ลองเสนอทางแก้แบบร่าง แทนที่จะถามในที่ประชุมว่า “ควรใช้ pattern ไหนดี” ให้ลองเขียน draft PR หรือ diagram คร่าว ๆ มาก่อน แล้วถามว่า “แบบนี้พอไปได้ไหม” คำตอบที่ได้มักเจาะจงและเร็วกว่า
- สร้างวัฒนธรรมที่การแก้ไขคำตอบผิดไม่ใช่เรื่องน่าอาย กฎนี้ทำงานได้ก็ต่อเมื่อคนกล้า post สิ่งที่อาจผิด ถ้าทีมมีวัฒนธรรมตำหนิคนที่ผิด (blame culture) แรงจูงใจที่จะเสนอ draft ก็จะหายไป และกฎนี้จะไม่ทำงาน
- ระวังการใช้ผิดจุดประสงค์ อย่าใช้กฎนี้เป็นข้ออ้างในการ post ข้อมูลผิดโดยเจตนาเพื่อยั่วยุ (troll) หรือดึงความสนใจ เพราะนอกจากจะทำลายความน่าเชื่อถือแล้ว ยังสร้างความเสียหายในกรณีที่ไม่มีใครมาแก้ไขทันเวลา (เช่น คำแนะนำด้านความปลอดภัยที่ผิด)
- ในการเขียนเอกสาร ให้ favour ตัวอย่างเป็นรูปธรรมมากกว่าคำถามลอย ๆ เมื่อขอ feedback บนเอกสารหรือ Architecture Decision Record (ADR) การเขียนข้อเสนอที่ชัดเจน แม้จะยังไม่สมบูรณ์แบบ มักได้ความเห็นที่ตรงประเด็นกว่าเอกสารที่ทิ้งคำถามเปิดไว้เฉย ๆ
flowchart LR
Ask[ตั้งคำถามเปิดกว้าง] --> Silence[มักถูกเงียบใส่]
Draft[เสนอคำตอบแบบร่างที่อาจผิด] --> Trigger[กระตุ้นสัญชาตญาณอยากแก้ไข]
Trigger --> Fix[มีคนรีบเข้ามาแก้ไขให้ถูก]
Fix --> Better[ได้คำตอบที่ดีขึ้นเร็วกว่า]
ที่เกี่ยวข้อง
หัวข้อที่มีชื่อว่า “ที่เกี่ยวข้อง”- Rubber Duck Debugging — อีกเทคนิคที่ใช้ “การอธิบายให้ใครสักคนฟัง” (แม้เป็นเป็ดยาง) เพื่อดึงคำตอบออกมาจากตัวเอง
- Read the Manual — คู่ตรงข้ามเชิงพฤติกรรม: บางครั้งคำตอบที่ถูกที่สุดหาได้จากการอ่านเอกสารเอง ไม่ต้องรอให้ใครมาแก้
- Linus’s Law — หลักการที่ใกล้เคียงกันในบริบท open source: ยิ่งมีคนตรวจสอบมาก bug ก็ยิ่งถูกจับได้ง่าย เช่นเดียวกับที่คำตอบผิดถูกแก้ไขเร็ว
- Pair Programming — การมีคู่คิดตลอดเวลาช่วยลดการเงียบใส่คำถาม เพราะมีคนพร้อมโต้แย้งทันทีที่เห็นแนวทางที่น่าสงสัย
- Collective Code Ownership — วัฒนธรรมที่ทุกคนกล้าแก้ code ของกันและกัน เป็นเงื่อนไขที่ทำให้ปรากฏการณ์แบบ Cunningham’s Law เกิดขึ้นได้ในทีมพัฒนา