माझ्या डेटाबेसने मला फसवले आहे हे समजण्यापूर्वी मी तुलनात्मक तक्ते (comparison tables) तयार करण्यात महिने घालवले.

इंटरफेस व्यवस्थित दिसत होता. स्वच्छ ओळी, नीट चेकमार्क्स, आणि एखादे टूल अपुरे असल्यास लाल 'X' मार्क्स. भेट देणारे लोक ते स्क्रोल करायचे आणि अधूनमधून त्यावर क्लिक करायचे. पण पृष्ठभागाखाली, स्कीमा (schema) शांतपणे प्रत्येक निष्कर्षाला भ्रष्ट करत होता. मी खराब डेटावर एक सुंदर UI तयार केले होते.

बुलियनचा सापळा (The Boolean Trap)

तुलना करणारे पेजेस सहसा एका स्पष्ट पॅटर्नने सुरू होतात. तुम्ही एक ग्रिड तयार करता जिथे ओळी (rows) वैशिष्ट्ये (features) असतात, स्तंभ (columns) उत्पादने असतात आणि प्रत्येक सेलमध्ये एक बुलियन (boolean) असतो. 'True' म्हणजे त्या टूलमध्ये ते वैशिष्ट्य आहे. 'False' म्हणजे ते नाही. काही काळ, हे व्यवस्थित वाटते. पण जेव्हा तुम्ही दोन प्रोजेक्ट मॅनेजमेंट टूल्स, किंवा तीन क्लाउड डेटाबेस, किंवा चार API गेटवेची तुलना करण्याचा प्रयत्न करता, तेव्हा ते ग्रिड बंडखोर होऊ लागते.

बुलियन सेल्समध्ये सूक्ष्मता (nuance) असू शकत नाही. जेव्हा एखादा सेल 'false' दर्शवतो, तेव्हा त्याचे पाच पूर्णपणे वेगळे अर्थ असू शकतात. कदाचित त्या टूलमध्ये खरोखरच त्या क्षमतेचा अभाव असू शकतो. कदाचित ते त्याच समस्येचे निराकरण वेगळ्या पद्धतीने करत असेल. कदाचित ते वैशिष्ट्य उपलब्ध आहे पण ते 'enterprise paywall' च्या मागे आहे. कदाचित त्यासाठी तुम्हाला न दिसणारे एखादे प्लगइन आवश्यक असेल. किंवा कदाचित तुम्ही ते तपासण्यास विसरला असाल आणि तो लाल 'X' फक्त तुमच्या स्वतःच्या अनिश्चिततेचा एक भाग असेल.

हे महत्त्वाचे आहे कारण वापरकर्ते महागडे निर्णय घेण्यासाठी तुलनात्मक ग्रिड्सवर विश्वास ठेवतात. जेव्हा तुम्ही एखाद्या CLI-आधारित टूलमध्ये 'real-time collaboration' नाही असे मार्क करता, तेव्हा तुमचा अर्थ असा असू शकतो की त्यात 'live cursor sharing' नाही. परंतु तेच टूल कदाचित तेच परिणाम मिळवण्यासाठी 'branch-based workflows' आणि 'review queues' वापरत असेल. त्याला 'false' म्हणून मार्क करणे म्हणजे एका डिझाइन निवडीला दोष ठरवणे होय. असे वीस वैशिष्ट्यांमध्ये केल्यास तुम्ही दोन टूल्सची तुलना करत नाही, तर तुम्ही त्यातील एकाला दोषपूर्ण घोषित करता.

बुलियन स्कीमा तुम्हाला वापरकर्त्यांच्या गरजांऐवजी विक्रेत्यांच्या (vendor) शब्दसंग्रहात विचार करण्यास प्रवृत्त करतो. जर तुमच्या ओळी (rows) श्रेणीतील लीडरकडून (category leader) नावांची घेत असतील, तर तुम्ही प्रत्येक स्पर्धकाकडे 'Workspaces' आहेत का, हे विचारू लागता कारण Notion त्यांना 'Workspaces' म्हणते. दुसरे टूल त्यांना 'Projects' म्हणते. तिसरे टूल कदाचित कोणतेही समर्पित कंटेनर देत नाही, परंतु तुम्हाला तेवढेच विलगीकरण (isolation) मिळवण्यासाठी वैयक्तिक फाइल्सना परवानगी (permission) देण्याची सुविधा देते. तुमच्या ओळींची नावे प्रत्येक उत्पादनाला लीडरच्या मानसिक मॉडेलमध्ये अडकवतात, जे मार्केटमधील मोठ्या कंपनीसाठी सोयीचे आहे परंतु इतरांसाठी अन्यायकारक आहे.

स्थितीसाठी (Status) अधिक चांगला शब्दसंग्रह

यावर उपाय डेटा प्रकारापासूनच सुरू होतो. बुलियन साठवणे थांबवा. स्पष्ट शब्दसंग्रह असलेले 'status field' वापरा.

या सहा स्थितींचा विचार करा.

Full म्हणजे ते टूल कोणत्याही पर्यायी मार्गाशिवाय (workarounds) किंवा अतिरिक्त खरेदीशिवाय काम पूर्ण करते.

Partial म्हणजे ते काही प्रमाणात काम करते, किंवा एखादी गुंतागुंतीची रचना (configuration) केल्यावरच ते काम करते. बहुतेक तुलनांमध्ये चुकीची माहिती याच ठिकाणी लपलेली असते. जे टूल एन्क्रिप्शन देते पण ते फक्त 'at rest' स्थितीसाठी असते, त्याला 'Partial' म्हटले पाहिजे, 'Full' नाही.

Different Model म्हणजे समस्या सुटते, पण श्रेणीतील लीडर ज्या पद्धतीने सोडवतो त्या पद्धतीने नाही. 'branches' आणि 'reviews' असलेले CLI टूल या श्रेणीत येते. तसेच ते डेटाबेस देखील जे 'single pooled connection' ऐवजी 'read replicas' वापरतात. ही स्थिती स्पर्धकाची नक्कल न केल्याबद्दल उत्पादनाच्या डिझाइनला शिक्षा देण्याऐवजी त्याच्या बुद्धिमत्तेचा आदर करते.

Not Applicable म्हणजे ती संकल्पना या प्रकारच्या टूलला लागूच होत नाही. व्हर्च्युअल मशीनप्रमाणे 'serverless function platform' ला 'persistent local storage' ची गरज नसते. तिथे 'false' मार्क करणे म्हणजे श्रेणीबद्दलचा गोंधळ आहे.

Absent म्हणजे तुम्ही तपासले आहे आणि ती क्षमता खरोखरच नाहीये. तिथे कोणताही पर्यायी मार्ग, प्लगइन किंवा वेगळी कार्यपद्धती नाही. ती कमतरता वास्तविक आहे.

Unknown म्हणजे तुम्ही ते तपासलेले नाही.