Tony Hoare 在 1980 年图灵奖的演讲中建议，“构造软件设计有两种方法：一种是简单，明显地没有缺陷；另一种方法是使其复杂，却没有明显的缺陷。”提到了由于复杂度而导致的非明显的缺陷是如何伤害我们的，以及我们该如何应对这些成本？
下面是你能够用到的一些策略：
为简单而优化。抵制增加更多复杂的主张。深思维护成本。要自问，为了解决 20% 的问题而引入的复杂是否值得，或者 80% 的解决方案已经足够了。
为你的团队或产品定义一种任务说明以统一思想。在 Team Geek，Brian W. Fitzpatric 和 Ben Collins-Sussman 解释了他们是如何辅导 Google Web Toolkit（GWT）团队、并鼓励他们写下任务说明的。接下来发生的、对于任务说明的内容和形式的争论，表明了首席工程师并不真正认同产品方向！他们被迫面对、协调不同、并最终达成了，“GWT 的任务是为用户彻底提升 web 体验，让开发者使用现有的 Java 工具在任意现代浏览器里构建高性能的 AJAX。”如果他们不能尽早找出这些区别，随之而来的努力上的分散又有多少呢？
用较小的构建块组成大型系统。Google 就是个例子，致力于构建健壮的核心抽象，然后被非常宽泛的应用程序广为使用。他们有基础的构建块，像 Protocol Buffers、Google File System 和远程程序调用的 Stubby 服务器。基于这些构建块之上，他们还建立了其它抽象，比如 MapReduce 和 BigTable。在此之上，包括大型 web 索引、Google Analytics 站点追踪、Google News 聚合、Google Earth 数据处理、Google Zeitgeist 数据分析在内的数以千计的应用程序，还有很多程序都是这样构建的。
清晰地定义模块和服务之间的接口。模块和服务的退耦，将减少能够产生一堆代码的组合复杂度。在 Amazon，Jeff Bezos 于 2002 年宣称，公司将转向面向服务的架构，所有团队只能通过服务层级的接口彼此交流。虽然这个转变造成了本身巨大的开发成本，但是它强制分离了代码和服务背后的逻辑，为现在极度成功的 Amazon Web Services 的建立提供了便利。
优先偿还技术债务。我们总是在信息不完全的条件下开发软件。做为条件变化的响应，代码库在增大，熵也在增大。增加的复杂度成为了未来开发的代价。在开发日常上预算时间可以减少这项成本。很多工程师和团队在项目之间预算这项时间，不过召开一次性的会议会有帮助。我过去在 Quora 组织过一次 Code Purge Day（代码消除日）活动，工程师在这一天全部关注删除无用代码的工作。我们在积分牌上追踪代码消除的进度，这使得删除你自己的代码更有趣味。
使用数据修剪没用的功能。在 Yammer，当工程师或产品经理发现在代码重构时，强化或保留一个功能将花费不菲的时间时，他们将查看使用数据，以确定这项功能是否真正被使用了。如果没有，他们将和团队一起决定，他们是否应该只是砍掉这个功能以降低总体工作量。与简化的代码是怎样减少技术债务一样，这个策略也减少了技术债务。
基于主题对进行中的项目分组。使同事彼此分享同样的环境，更容易地参与到设计讨论、代码评审或构建可复用的资源库。所有这些活动有助于提供检查和平衡掉单个人或其他人所引发的问题。
当我们为学校课程开发软件时，我们有着世界的过于简单的视角——维护任意复杂度的成本随着下课而消失了。但是在我们的职业生涯中，糟糕的软件决定将产生数年负担的影响。
不要使事情复杂化。