कोई पूर्ण उत्तर नहीं है, और यही बात है। Speed बनाम maintainability संदर्भगत है — आप कठोरता को code के और से मिलाते हैं। एक throwaway prototype और एक payments core बहुत अलग bars के हकदार हैं। lead का काम है उस trade-off को बनाना, इसे संयोग से होने न देना।
कोई corner काटने से पहले तीन प्रश्न पूछें:
// TODO, RFC में एक note)। आप ठीक-ठीक जानते हैं कि आपने क्या trade किया और क्यों।दबाव में भी core को साफ़ रखें: well-named boundaries, tested critical paths। गंदगी को किनारों की ओर धकेलें जहां इसे फाड़ना सस्ता है।
जब deadline तंग हो, तो ईमानदार कदम है stakeholders के साथ scope या time को फिर से negotiate करना — कुछ भंगुर चुपचाप ship न करना। "हम feature A और B के साथ तारीख पर पहुंच सकते हैं, लेकिन C एक हफ़्ता slip होता है" एक वास्तविक बातचीत है। भंगुर code को चुपचाप ship करना team की भविष्य की velocity खर्च करता है बिना किसी के सहमत हुए।
जो teams हमेशा speed के लिए optimize करती हैं वे debt में डूब जाती हैं; जो teams हमेशा gold-plate करती हैं वे markets चूक जाती हैं। lead का मूल्य judgment है — कठोरता को संदर्भ से calibrate करना और trade-off को दृश्य और owned बनाना, ताकि आज का shortcut एक ऐसा चुनाव हो जिसे team चुका सके, न कि एक आश्चर्य जो उसे विरासत में मिले।