بیشتر بازنویسی‌ها به سه انتخاب در دو هفته اول برمی‌گردند، مدت‌ها پیش از آنکه کسی اطلاعات کافی برای انتخاب درست داشته باشد. پرسش مفید این نیست که چگونه از آن انتخاب‌ها بگریزیم، بلکه این است که کدام‌یک ارزش یک هفته بحث دارند و کدام‌یک را می‌توان در یک ساعت تصمیم گرفت.
سه دسته در برابر تغییر رفتار متفاوتی دارند. کد ارزان جایگزین می‌شود. رابط میان سیستم‌ها گران است. مدل داده گران‌ترین است، چون هر تصمیم دیگری در نهایت فرضی درباره آن را در خود ثبت می‌کند و آن فرض‌ها جایی می‌مانند که کسی به فکر بازبینی‌شان نیست.
اول پرونده را تصمیم بگیرید، بعد فریم‌ورک را
در یک پروژه جایگزینی، هفته‌های اول باید تقریباً هیچ رابطی تولید نکنند. آنچه باید تولید کنند، همان پرونده‌ای است که تمام سیستم‌های درگیر بتوانند بر آن توافق کنند. هر صفحه‌ای که بعد ساخته می‌شود، نمایی روی همان پرونده است؛ و همین است که جایگزینی یک ماژول را بعداً به کاری دوهفته‌ای تبدیل می‌کند نه یک فصل.
اگر بازگشت از تصمیمی سخت است، آن یک هفته را صرف کنید. اگر بازگشت آسان است، بحث را تمام کنید و چیزی منتشر کنید که از آن یاد بگیرید.
سه پرسشی که پیش از نوشتن کد می‌پرسیم
- وقتی حجم ده برابر و تیم نصف شود، چه بر سر این طراحی می‌آید؟
- کدام بخش از این را مهندسان خود مشتری باید بدون ما اداره کنند؟
- اگر این فرض در ماه هشتم غلط از آب دربیاید، هزینه اصلاح چقدر است؟
پرسش سوم همان است که برنامه‌ها را تغییر می‌دهد. بحث بر سر سلیقه را به یک برآورد تبدیل می‌کند، و توافق بر برآورد آسان‌تر از توافق بر نظر است.
-- one record, every system reads the same shape
create table account (
id uuid primary key,
external_refs jsonb not null default '{}', -- legacy system ids
created_at timestamptz not null default now()
);هیچ‌کدام از این‌ها تازه نیست. این فقط ترتیب کاری است که در برخورد با یک ضرب‌الاجل واقعی دوام می‌آورد، و دلیل اینکه کشف را به‌عنوان مرحله‌ای پرداختی اجرا می‌کنیم، نه فعالیت فروش.
