第一章的标题“死定了”（Deadline），一语双关——既指项目截止日期，也暗示着团队的状态。
《梦断代码》讲述的是OSAF基金会开发Chandler项目的真实故事。故事的起点令人振奋：Mitchell Kapor——Lotus 1-2-3的创造者——带领几十号顶尖软件高手，组建团队，投入上百万美元，目标是打造一个能够击败微软Outlook的“通用信息管理器”。计划用一到两年完成，结果花了七年才勉强推出，却已无人喝彩。
Chandler团队遇到的第一个核心问题是：没有蓝图。传统工程在动工之前有详细的设计图纸，每一根梁、每一颗螺丝的位置都预先确定。但软件开发中，所谓的“设计文档”往往只是一份模糊的需求描述，距离真正的“施工图”相去甚远。没有蓝图，就意味着你无法提前预料到所有问题——依赖的库出了bug要等待修复，接口文档不清晰要反复沟通，需求一变就要推倒重来。
这让我想起了布鲁克斯定律的现场演绎：“往已延误的项目中补充人力，只会使其继续延误。”Chandler团队在进度落后时也曾尝试加人，但新成员需要时间理解系统，反而拖慢了原有节奏。
书中引用了一组令人警醒的数据：实际开发中，编码只占软件项目总时间的六分之一，有一半时间用于测试和修正缺陷。这意味着，当你以为完成了80%的编码工作时，实际上可能只完成了20%的总工作量。这种认知偏差，是无数软件项目延误的根源。
作为一个软件工程专业的学习者，这一章让我意识到，做一个课程作业和做一个真正的软件项目之间有着天壤之别。前者可以在几天内完成，后者却可能耗费数年、数百万美元，最终仍然以失败告终。软件开发中的问题从来不只是技术问题，更是人的问题、沟通的问题、估算的问题、管理复杂性的问题