航天飞行器设计师可能还比软件工程师要负责，借鉴一下航天飞机设计定律，学习成为一个更好的软件工程师。
航天飞行器是一个复杂的系统，软件也是。
这些定律对项目管理，对产品管理、代码、设计都可以类比一下反思一下。
这些设计定律来自 Dave Akin，干了一辈子航天器和太空系统设计与开发工作，包括讲授航天器设计课程。
先是在麻省理工教了10年，在马里兰大学又教了20年。
在此期间他收集了不少隽语。一些是他人的，更多是他自己的。
Akin 最初写下这些是为了在课堂上作为设计经验的提示，之后有朋友说在其他地方看到了这些定律，并高度赞扬。
- 工程设计的实现依赖于数据。没有数据的分析仅仅只是一种观点罢了。
- 设计一个好的飞船会付出无限的努力。这就是为什么在问题出现的时候再去通过设计使他们运行是好的。
- 设计是一种迭代的过程。必要的迭代次数在你目前正在做的次数上+1。
- 你尽全力做出的最好设计可能会在最终的设计中变得毫无用处。要学会在失望中生存。
- Miller 定律：3点决定一个曲线。
- Miller 定律：当用一个大粗笔画 log-log 坐标时，所有的东西都会是线性的。
- 在任何设计之初，最想当团队 leader 的那个人很可能是看起来是最没有能力胜任的人。
- 自然界中，最好的通常会在中部。对那些出现在极端点的最好的东西持怀疑态度。
- 没有足够的信息永远不能成为你不开始分析的借口。
- 有怀疑，就判断。很紧急，可猜测。但一定要在真实数据出来后重新进行整理，清理错误。
- 某些时候，通往终点最快的方法是抛开一切，立马开始。
- 问题永远不会只有一种解决方案。即使错误的方式有一堆。
- 设计要基于需求。某个东西设计得比需求要求的“更好”，并不是一个正当的行为。
- Edison 定律：“更好” 是 “好” 的敌人。
- Shea 定律：提升设计的能力最初体现在接口。这也是最初可以把他搞砸的地方。
- 前人所做的类似分析可能并没有年代所累积的智慧。没有理由去觉得他们的分析比你的更可信或者据为己有。
- 分析被公众于世这件事与它正确的可能性无关。
- 过往经历是一种极好的判断设计是否现实的能力。但过于现实同样会毁了一个在其它方面有价值的设计。
- 众多的可能性会阻止你变得比世上任何人都聪明。
- 一个坏的设计加上一个好的说明终究会完蛋。一个好的设计加上一个坏的说明会立马完蛋。
- Larrabee定律：你在课堂里听到的一半东西都是垃圾。教育的目的是来让你知道哪一半是垃圾。
- 有疑问，写下来。(文档方面的要求会在一个程序完成后的短时间里达到最高峰。)
- 给开发定计划总像是在虚构一个小说，直到当你的客户因为你没有按计划完成而炒了你时你才知道它的意义。
- “工作执行会破坏架构”，因为要做的工作会不断增加，直到出现了问题，除非你强迫架构适应这种情况。
- Bowden 定律：寻找测试失败的可能，永远可能改进你的分析设计，这显示了你真的进行了边界分析。
- Montemerlo 定律：不要做哑巴。
- Varsi 定律：工作计划只会向一个方向变化。
- Ranger 定律：世上没有免费的发射。
- Tiesenhausen 项目管理定律：为了精确的估出最终的投入，把初估时乘以π，把估的成本的小数点右移1位。
- Tiesenhausen 工程设计定律：如果你愿意往一个新设计的系统中投入最大的精力，那就学绘画。图片说明。
- Mo 演化发展定律：你不可能通过爬到更高的树上来到达月亮。
- Atkin demo 定律：当硬件工作完美正常时，真正重要的访问者不会出现。
- Patton 计划定律：一个好的计划热火朝天的立马开工比一个下周的完美的计划更好。
- Roosevelt 任务规划定律：根据你拥有的，在你所在的地方，尽你所能。
- Saint-Exupery 定律：一个设计师的完美的时候，不是没什么可以加上去的了，而是没什么可以被拿掉的了。
- 任何工程师都可设计出优美的东西。好的工程师设计系统来达到高效。更好的工程师设计系统来达到有效。
- Henshaw 定律：一件任务的成功关键是明确各自的责任。
- 不管系统工程教科书怎么说，性能驱动需求。
- 任何“恰好”包括一个新的运载火箭的探索计划，实际上都是一个运载火箭计划。
- 保证新的太空项目预算足够并按计划有3个关键：没有新的火箭，没有新的火箭，不要开发任何新的火箭。
- McBryan 定律：你不能使它变得更好，除非你先使它工作。
- 如果你说一直以来都没有足够的时间去做好，但某种程度上，其实一直都有把它做完的时间。
- 太空是一个完全无情的环境。如果你在工程中搞砸了，某人会死。
推荐：