فصل اول کتاب درباره‌ی پیچیدگی صحبت می‌کند؛ اینکه پیچیدگی چیست، کجا رخ می‌دهد و چگونه به بهره‌وری شما آسیب می‌رساند.
دقت کنید که این مطلب ترجمه‌ی خط به خط کتاب نیست و فقط قسمت‌های مهم آن آورده شده است.
در زمینه‌های مختلف، عبارت پیچیدگی معناهای متفاوتی دارد. در این کتاب پیچیدگی را این چنین تعریف می‌کنیمیک کل که از اجزایی تشکیل شده است که تحلیل، فهمیدن یا توضیح دادن این کل، سخت است.
بر اساس استاندارد IEEE برای مهندسی نرم‌افزار، یک پروژه‌ی نرم‌افزاری شامل ۶ مرحله است:
حتی در پروژه‌های نرم‌افزاری کوچک هم این مراحل طی می‌شوند. لزوما هر مرحله یکبار انجام نمی‌شود و ممکن است یک مرحله را چند بار انجام دهیم.
برنامه‌ریزی، اولین مرحله از چرخه‌ی زندگی توسعه‌ی نرم‌افزار است که در ادبیات مهندسی با نام تحلیل نیازمندی‌ها (Requirement Analysis) نیز شناخته می‌شود. هدف این مرحله این است که مشخص شود محصول چگونه خواهد بود. یک برنامه‌ریزی موفق، منجر به تعریف دقیق فیچرهای مورد نیاز برای تحویل به کاربر نهایی می‌شود.
اگر خودتان به تنهایی بر روی یک پروژه کار می‌کنید یا مسئول مدیریت همکاری‌ها بین چند تیم توسعه‌ی نرم‌افزار هستید، باید مجموعه‌ی فیچرهای بهینه‌ی نرم‌افزار را به دست بیاورید.
چند فاکتور باید در نظر گرفته شود: هزینه‌ی تولید یک فیچر، میزان ریسک عدم توانایی در پیاده‌سازی موفقیت‌آمیز فیچر، ارزش مورد انتظار کاربر نهایی، بازاریابی، قابلیت نگه‌داری، مقیاس‌پذیری و ...
این مرحله مهم است چون می‌تواند از هدر رفت انرژی و منابع مالی در آینده جلوگیری کند.
این مرحله شامل تبدیل نتایج بخش برنامه‌ریزی به نیازمندی‌های نرم‌افزاری مشخص است. به عبارت دیگر، خروجی مرحله‌ی قبل را به‌صورت رسمی تعریف می‌کند تا از کاربران نهایی که بعدها قرار است از این محصول استفاده کنند، فیدبک و تاییدیه دریافت شود.
اگر زمان زیادی را صرف برنامه‌ریزی کرده‌اید اما نتوانستید آن را به خوبی انتقال دهید، بعدها مشکلات و سختی‌های زیادی را ایجاد خواهد کرد. نیازمندی‌هایی که به غلط تعریف شده‌اند و به پروژه کمک می‌کنند دقیقا به بدی نیازمندی‌هایی هستند که به خوبی تعریف شده‌اند اما به پروژه کمکی نمی‌کنند.
اگر بخواهید ایده‌ها (در اینجا نیازمندی‌ها) را سرسری از ذهن خود به ذهن دیگری انتقال دهید، در دام پیچیدگی خواهید افتاد!
هدف این مرحله، تهیه‌ی یک پیش‌نویس از معماری سیستم، طراحی رابط کاربری و تصمیم‌گیری برای ماژول‌ها و اجزایی که عملکردهای تعریف شده را تحویل می‌دهند است. حین انجام این کار، به نیازمندی‌هایی که در مراحل قبلی تولید شده‌اند توجه می‌کنیم.
استاندارد طلایی این مرحله این است که یک تصویر شفاف از نرم‌افزار نهایی بسازیم و بدانیم که محصول نهایی چه ظاهری خواهد داشت و چگونه ساخته خواهد شد.
این مرحله جایی است که بیشتر کدنویس‌ها دوست دارند زمان‌شان را صرف کنند. اینجا جایی است که پیش‌نویس معماری به محصول نرم‌افزاری تبدیل می‌شود.
با آماده‌سازی‌های مناسب در مراحل قبلی، بسیاری از پیچیدگی‌ها حذف شده‌اند. سازندگان باید بدانند که از بین تمام فیچرها، کدام فیچرها را پیاده‌سازی کنند، این فیچر چه شکلی خواهد داشت و از چه ابزاری برای پیاده‌سازی آن استفاده کنند.
تمام فیچرهای خواسته شده پیاده‌سازی شده‌اند و به نظر می‌آید برنامه کار می‌کند. اما هنوز کار شما تمام نشده است. باید عملکرد برنامه را برای ورودی‌ها و طرز استفاده‌های مختلف آزمایش کنیم. معمولا این مرحله مهم‌ترین مرحله است؛ به طوری که بسیاری از فعالان حوزه‌ی نرم‌افزار، از توسعه‌ی مبتنی بر تست (test-driven development) دفاع می‌کنند. در این نوع توسعه، بدون نوشتن تمام تست‌ها، روند توسعه شروع نمی شود.
حال نرم‌افزار مرحله‌ی تست را گذرانده است و آماده‌ی انتشار است. انتشار می‌تواند صورت‌های مختلفی داشته باشد. یک نرم‌افزار ممکن است در مارکت‌پلیس یا یک repository منتشر شود. این مرحله ممکن است با استفاده از Continuous Deployment چندین بار انجام شود. بسته به پروژه، ممکن است در این مرحله مجبور باشید محصول را منتشر کنید، کمپین‌های تبلیغاتی بسازید و با کاربران اولیه‌ی محصول صحبت کنید و باگ‌های آن را برطرف کنید.
