तुमचे काम केवळ कोड लिहिणे नाही. ते निर्णय घेणे आहे. तुम्ही त्यातून शिकता. काळानुसार तुम्ही चुका कमी करता. शेवटी, तुम्ही इतरांना त्याच धुक्यातून (अस्पष्टतेतून) मार्ग दाखवता. तो प्रवास—केवळ लॉजिक लिहिण्यापासून ते परिणामांची जबाबदारी स्वीकारण्यापर्यंत—एखाद्या सिंटॅक्स टाईप करणाऱ्या व्यक्तीला आणि सिस्टिम्स बनवणाऱ्या व्यक्तीला वेगळे करतो.

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

सुरुवातीच्या निवडींचा परिणाम (Blast Radius)

जेव्हा तुम्ही सुरुवात करत असता, तेव्हा तुमच्या चुका एका छोट्या खोलीतच मर्यादित राहतात. एक चुकीचा commit स्थानिक build बिघडवतो. एक निष्काळजी function एका स्क्रीनचा वेग कमी करते. त्याचा परिणाम (blast radius) मर्यादित राहतो. तुम्ही कमी लोकांवर परिणाम करता आणि सुधारण्यासाठी कमी खर्च येतो.

पण जसजसे तुम्ही प्रगती करता, मग तुम्ही एक वैयक्तिक इंजिनिअर म्हणून असो किंवा कंपनी म्हणून, तुमचे निर्णय अधिक सिस्टिम्सवर परिणाम करतात. त्याच निवडी मोठ्या प्रमाणावर (at scale) केल्यास आठवड्यांचा खर्च येऊ शकतो. म्हणूनच, किंमत वाढण्यापूर्वी तुम्हाला आताच मोजून-मापून निर्णय घेण्यास शिकले पाहिजे.

तीन सामान्य जाचांचा (traps) विचार करा:

  • अशी प्लॅटफॉर्म वापरणे ज्याला तुमचे dependencies सपोर्ट करत नाहीत, यामुळे इंजिनिअरिंगचे डझनभर किंवा शेकडो तास वाया जाऊ शकतात. ते तास केवळ टाईप करण्यासाठी नसतात. ते विचित्र compatibility समस्या सोडवण्यासाठी, transitive libraries पॅच करण्यासाठी आणि स्टेकहोल्डर्सना हे समजावून सांगण्यासाठी खर्च होतात की एक साधे feature पूर्ण तिमाही का घेते.

  • उत्पादनाच्या सुरुवातीच्या काळात session-based authentication कडून JWTs कडे वळल्यामुळे नंतर होणारा मोठा खर्च वाचतो. जेव्हा तुमच्याकडे हजारो वापरकर्ते असतात, तेव्हा login logic रिफॅक्टर करणे सोपे असते, त्या तुलनेत जेव्हा लाखो वापरकर्ते असतात आणि downtime मुळे प्रत्यक्ष आर्थिक नुकसान होते, तेव्हा ते कठीण असते.

  • वेळेचा अंदाज तुमच्या सर्वोत्तम अंदाजाच्या दुप्पट घेणे तेव्हाच फायदेशीर ठरते जेव्हा तुम्ही तो 'बफर' (buffer) गुणवत्तेचे रक्षण करण्यासाठी वापरता. सोशल मीडिया स्क्रोल करण्यासाठी वेळापत्रक वाढवणे म्हणजे वाया घालवणे आहे. पण tests लिहिण्यासाठी, edge cases तपासण्यासाठी आणि observability पडताळण्यासाठी वेळ वाढवणे ही एक गुंतवणूक आहे.

येथे एक साधी पद्धत आहे: technical debt वाढत जातो. जेव्हा तो कमी असतो, तेव्हाच तो फेडून टाका.

डेडलाईन्स आणि नियंत्रणाचा आभास

डेडलाईन्स सर्वत्र आहेत. release dates, demo dates, code freezes. मोठ्या कंपन्यांमध्ये ते तांत्रिक कारणांपेक्षा अनेकदा मनोवैज्ञानिक कारणांसाठी वापरले जातात. ते अशा गुंतागुंतीवर नियंत्रणाचा भास निर्माण करतात जी कोणालाही पूर्णपणे समजत नाही.

याचा परिणाम अपेक्षित आहे. जशी डेडलाईन जवळ येते, तशी गुणवत्ता कमी होते. टीम्स tests काढून टाकतात, error handling कमेंट आउट करतात आणि असा कोड ship करतात जो कोणालाही मेंटेन करायचा नसतो. डेडलाईन पूर्ण होते. कॅलेंडर स्वच्छ दिसते. पण उत्पादन (product) बिघडलेले असते.

असे घडते कारण इंजिनिअर्सना परफेक्ट कोड आणि उत्कृष्ट आर्किटेक्चर आवडते. हे आपल्या स्वभावात आहे. पण परिपूर्ण उत्तर नेहमीच उपलब्ध नसते. योग्य निवड तीच असते जी तुमच्या टीमच्या सध्याच्या स्थितीला साजेसी असते. तीन लोकांच्या स्टार्टअपला नियमांनी बांधलेल्या हेल्थकेअर प्लॅटफॉर्मसारख्या औपचारिकतेची (ceremony) गरज नसते. तुम्ही जिथे आहात तिथल्या परिस्थितीनुसार काम करा, पाच वर्षांपूर्वी हजारो इंजिनिअर्सची संस्था जिथे होती, त्यावरून काम करू नका.

जेव्हा वाढीमुळे जुने नियम मोडले जातात

नेतृत्व (leadership) अनेकदा एक गोष्ट misses करते. जशी कंपनी वाढते, तशा डेडलाईन्स देखील वाढल्या पाहिजेत. प्रक्रिया विस्तारतात. नवीन लोक येतात आणि त्यांना ऑनबोर्डिंगची गरज असते. उत्पादने वाढल्यामुळे कामेही वाढतात. अनुपालन (compliance) आवश्यकता वाढतात—अंतर्गत सुरक्षा पुनरावलोकने, बाह्य ऑडिट, डेटा गव्हर्नन्स तपासणी. कामाचा विस्तार वाढतो, पण शेवटची रेषा (finish line) तिथेच स्थिर राहते.

जास्त कामासाठी त्याच डेडलाईन्स वापरल्याने टीम वेगवान होत नाही. उलट, ते निष्काळजी बनवतात. कामात तडजोड केली जाते. डॉक्युमेंटेशन गायब होते. incident response केवळ प्रतिक्रियात्मक (reactive) होतो. जे इंजिनिअर्स एकेकाळी स्वच्छ कोड ship करत होते, ते आता केवळ तात्पुरते उपाय (bandages) शोधत आहेत कारण कॅलेंडर लवचिक नाही.

जर एखाद्या कंपनीला मोठ्या प्रमाणावर वेग हवा असेल, तर त्यांनी एकतर कामाचे समांतर मार्ग (parallel tracks) वाढवावे लागतील किंवा कालमर्यादा वाढवावी लागेल. तीन नवीन भरतींनंतरही जे sprint कठीण वाटत होते, त्यात तुम्ही सतत वाढणारा backlog कोंडू शकत नाही.

बफर (Buffer) तयार ठेवणे

तुम्हाला मानसिकदृष्ट्या स्थिर ठेवण्याची एक सवय: काहीतरी चुकणारच आहे असे गृहीत धरा. हे निराशावाद नाही, तर वास्तववाद आहे.

सिस्टिम्स फेल होतात. थर्ड-पार्टी APIs संथ होतात. प्रॉडक्ट मॅनेजरने काल ग्राहकाशी बोलल्यामुळे आवश्यकता बदलतात. जेव्हा तुम्ही अडचणींसाठी (friction) नियोजन करता, तेव्हा तुमच्या डेडलाईन्स प्रामाणिक राहतात. यामुळे तुम्हाला वेग आणि गुणवत्ता यापैकी निवड करण्याचे स्वातंत्र्य मिळते. त्या बफरशिवाय, प्रत्येक वेळी निवड तुमच्यासाठी आधीच केली जाते. तुम्हाला वेग निवडण्यास भाग पाडले जाते, ज्याचा अर्थ असा की तुम्हाला गुणवत्तेचा त्याग करावा लागतो.

तो बफर (buffer) म्हणजे शिकण्याची जागा देखील आहे. जर प्रत्येक तास केवळ feature work साठी वापरला गेला, तर build pipeline सुधारण्यासाठी, query layer refactor करण्यासाठी किंवा API contract चे दस्तऐवजीकरण करण्यासाठी कोणाकडेही जागा उरणार नाही. टीम कायमस्वरूपी तिच्या सध्याच्या velocity वरच अडकून राहते.

एका चुकीच्या बदल्यात दुसरी चूक करणे

आपण सध्या एका विचित्र तडजोडीकडे वेगाने वळत आहोत. आपण मानवी चुकांची जागा non-deterministic software errors ने घेत आहोत. Large language models कोणत्याही junior engineer पेक्षा वेगाने boilerplate तयार करू शकतात, tests सुचवू शकतात आणि documentation चा मसुदा तयार करू शकतात. पण ते हे पूर्ण आत्मविश्वासाने करतात, आणि ते अशा प्रकारे चुकीचे करतात की...