मुझे बताइए कि जो feature डेटाबेस, API और UI तीनों को छूता है, उसे आप कैसे scope करेंगे और कैसे शिप करेंगे।

तीन परतें समानांतर बनाने की जगह इसे खड़ी काटकर चरणों में शिप कीजिए। डेटा मॉडल और additive migration से शुरू कीजिए, फिर contract tests के साथ API, फिर feature flag के पीछे UI। कोई एक संकरा मामला जल्दी अंत से अंत तक चलाकर देखिए, क्योंकि गलत धारणाएं वहीं सस्ते में सामने आती हैं। pull requests इतनी छोटी रखिए कि कोई उन्हें एक बैठक में ढंग से review कर सके।

कुछ भी लिखने से पहले मुझे वह सबसे छोटा वर्जन चाहिए जो सच में काम का हो, क्योंकि जो कुछ spec होता है उसका आधा पहले release में ज़रूरी ही नहीं होता। फिर मैं एक पतली खड़ी परत बनाता हूं: एक field, एक endpoint, एक स्क्रीन, एक दो दिन में अंत से अंत तक चलती हुई। वहीं आपको पता चलता है कि डेटा मॉडल गलत है, और दूसरे दिन यह पता चलना नौवें दिन के मुकाबले कुछ भी नहीं है। migrations पहले जाती हैं और हमेशा additive होती हैं ताकि वे उस कोड से पहले शिप हो सकें जो उन्हें इस्तेमाल करता है। अगर UI कोई और बना रहा है, तो हम API का अनुबंध जल्दी तय कर लेते हैं और वे किसी mock या typed schema पर काम करते हैं ताकि कोई मेरे इंतज़ार में न अटके। pull request के लिहाज़ से मैं ऐसे बदलाव चाहता हूं जो reviewer के दिमाग में समा जाएं: migration और model एक में, endpoint और tests दूसरे में, UI तीसरे में, और सब एक बंद flag के पीछे merge। फिर हम उसे अंदरूनी तौर पर चालू करते हैं, फिर एक छोटे प्रतिशत के लिए। इस तरह अंधेरे में शिप करने ने मुझे एक से ज़्यादा बार बचाया है जब भार उम्मीद से बुरा निकला।