I spent months building comparison tables before I understood that my database was lying to me.

ผมใช้เวลาหลายเดือนในการสร้างตารางเปรียบเทียบ ก่อนที่จะเข้าใจว่าฐานข้อมูลของผมกำลังหลอกผมอยู่

อินเทอร์เฟซดูดีไม่มีปัญหา แถวที่สะอาดตา เครื่องหมายถูกที่เรียบร้อย และเครื่องหมาย X สีแดงในจุดที่เครื่องมือทำไม่ได้ ผู้เข้าชมเลื่อนดูและคลิกบ้างเป็นครั้งคราว แต่ภายใต้พื้นผิวนั้น โครงสร้างข้อมูล (schema) กำลังบิดเบือนทุกข้อสรุปอย่างเงียบๆ ผมได้สร้าง UI ที่สวยงามขึ้นบนข้อมูลที่แย่

กับดักของค่า Boolean

หน้าเปรียบเทียบมักจะเริ่มด้วยรูปแบบที่เห็นได้ชัด คุณสร้างตารางที่แถวคือฟีเจอร์ คอลัมน์คือผลิตภัณฑ์ และทุกเซลล์เก็บค่า boolean ค่า True หมายความว่าเครื่องมือนั้นมีฟีเจอร์นั้น ส่วน False หมายความว่าไม่มี ในช่วงแรกมันดูเหมือนมีความเป็นระเบียบ แต่เมื่อคุณพยายามเปรียบเทียบเครื่องมือจัดการโปรเจกต์สองตัว หรือฐานข้อมูลคลาวด์สามตัว หรือ API gateway สี่ตัว ตารางนั้นก็จะเริ่มขัดขืน

เซลล์แบบ boolean ไม่สามารถสื่อถึงความละเอียดอ่อนได้ เมื่อเซลล์แสดงค่า false มันอาจหมายถึงสิ่งที่แตกต่างกันโดยสิ้นเชิงถึงห้าอย่าง บางทีเครื่องมืออาจขาดความสามารถนั้นจริงๆ บางทีมันอาจแก้ปัญหาเดียวกันด้วยกลไกที่ต่างออกไป บางทีฟีเจอร์นั้นมีอยู่แต่ต้องจ่ายเงินระดับ Enterprise ถึงจะใช้ได้ บางทีมันอาจต้องใช้ปลั๊กอินที่คุณไม่ได้สังเกต หรือบางทีคุณอาจแค่ลืมตรวจสอบมัน และเครื่องหมาย X สีแดงก็เป็นเพียงตัวแทนของความไม่แน่ใจของคุณเอง

เรื่องนี้สำคัญเพราะผู้ใช้เชื่อมั่นในตารางเปรียบเทียบเพื่อใช้ประกอบการตัดสินใจที่มีมูลค่าสูง เมื่อคุณทำเครื่องหมายว่าเครื่องมือแบบ CLI ขาดการทำงานร่วมกันแบบเรียลไทม์ คุณอาจหมายถึงมันไม่มีการแชร์เคอร์เซอร์แบบสดๆ แต่เครื่องมือตัวเดียวกันนั้นอาจใช้เวิร์กโฟลว์แบบ branch และคิวการรีวิวเพื่อให้ได้ผลลัพธ์แบบเดียวกันเป๊ะ การทำเครื่องหมายว่า false เป็นการลดทอนทางเลือกในการออกแบบให้กลายเป็นข้อบกพร่อง หากคุณทำแบบนั้นกับฟีเจอร์ยี่สิบอย่าง คุณไม่ได้กำลังเปรียบเทียบเครื่องมือสองตัว แต่คุณกำลังประกาศว่าตัวหนึ่งมันพัง

โครงสร้างแบบ boolean ยังฝึกให้คุณคิดด้วยคำศัพท์ของผู้ให้บริการแทนที่จะเป็นความต้องการของผู้ใช้ หากชื่อแถวของคุณหยิบยืมมาจากผู้นำในหมวดหมู่ คุณจะลงเอยด้วยการตั้งคำถามว่าคู่แข่งทุกรายมี Workspaces หรือไม่ เพียงเพราะ Notion เรียกมันว่า Workspaces ในขณะที่เครื่องมืออื่นเรียกมันว่า Projects และเจ้าที่สามอาจไม่มีคอนเทนเนอร์เฉพาะเลย แต่ยอมให้คุณกำหนดสิทธิ์ในแต่ละไฟล์จนได้ผลลัพธ์การแยกส่วน (isolation) แบบเดียวกัน ชื่อแถวของคุณกำลังบังคับให้ทุกผลิตภัณฑ์ต้องเข้าไปอยู่ในโมเดลความคิดของผู้นำตลาด ซึ่งมันสะดวกสำหรับยักษ์ใหญ่ในตลาด แต่ไม่ยุติธรรมสำหรับคนอื่นๆ เลย

คำศัพท์ที่ดีกว่าสำหรับสถานะ

วิธีแก้ไขเริ่มจากการเปลี่ยนประเภทข้อมูล เลิกเก็บค่า boolean แล้วเปลี่ยนมาเก็บฟิลด์สถานะ (status field) ที่ใช้คำศัพท์ที่ชัดเจนแทน

ลองพิจารณาสถานะทั้งหกนี้

Full หมายถึงเครื่องมือสามารถทำงานนั้นได้โดยไม่ต้องมีวิธีเลี่ยงหรือต้องซื้ออะไรเพิ่มเติม

Partial หมายถึงมันจัดการได้เพียงบางส่วน หรือจัดการได้ก็ต่อเมื่อคุณต้องตั้งค่าอะไรบางอย่างที่ซับซ้อน นี่คือจุดที่การเปรียบเทียบส่วนใหญ่มักซ่อนความไม่แม่นยำไว้ เครื่องมือที่เสนอการเข้ารหัส (encryption) แต่ทำได้เฉพาะขณะจัดเก็บ (at rest) ควรได้รับสถานะ Partial ไม่ใช่ Full

Different Model หมายถึงปัญหาได้รับการแก้ไขแล้ว เพียงแต่ไม่ใช่ด้วยวิธีที่ผู้นำในหมวดหมู่ทำ เครื่องมือ CLI ที่ใช้ branches และการรีวิวควรอยู่ในหมวดนี้ เช่นเดียวกับฐานข้อมูลที่ใช้ read replicas แทนที่จะใช้การเชื่อมต่อแบบ single pooled connection สถานะนี้ช่วยรักษาความชาญฉลาดในการออกแบบผลิตภัณฑ์ แทนที่จะลงโทษมันเพียงเพราะไม่ได้เลียนแบบคู่แข่ง

Not Applicable หมายถึงแนวคิดนั้นไม่สามารถนำมาใช้กับเครื่องมือประเภทนี้ได้ แพลตฟอร์ม serverless function ไม่จำเป็นต้องมีพื้นที่เก็บข้อมูลในเครื่องแบบถาวร (persistent local storage) เหมือนกับ virtual machine การฝืนใส่ค่า false ลงไปคือความสับสนในประเภทของผลิตภัณฑ์

Absent หมายถึงคุณได้ตรวจสอบแล้ว และความสามารถนั้นขาดหายไปจริงๆ ไม่มีวิธีเลี่ยง ไม่มีปลั๊กอิน ไม่มีเวิร์กโฟลว์ทางเลือก ช่องว่างนั้นมีอยู่จริง

Unknown หมายถึงคุณยังไม่ได้ตรวจสอบมัน