尽管有那些可能性——复杂度、延误和不可预知的改动——还是有许多软件写出来、交付出去、而且最终被使用。偶尔软件会很好。在一些罕见情形下，软件的确有创新和价值。在一些案例中，还真按计划达成了目标。

在这些稀有案例中，成功往往是铁一般纪律的副产品——一种坚决做出又在每次遇到挑战时大声重申的选择，限制着项目的范围。在软件的成功故事中，你总 能发现善于拒绝的人们。如同有意只在调色板上涂抹一种颜色的画家、宁肯写十四行诗也不写自由体诗歌的诗人，或者只固守小规模优势产品线的厂商一样，成功的 程序员也在约束中成长，而非没有约束。有时候，约束是环境的产物——预算少、时间紧、目标有限。有时，约束是有经验的程序员或经理强加给自己的，他们懂得 如何避开结局不可预料的——以软件界的说法来讲，“未绑定的”——项目。无论哪种情形，都更多地考虑“大即险”，而不是“小即美”。

约束是打造伟大产品的关键

有家位于芝加哥、名为37 Signals的小公司，正是这种拥抱限制的方式之代表者。37 Signals最初是一家网页设计资讯公司，后来为了满足自身需求而将业务扩展到软件开发领域。他们编写了一些用于项目管理的内部工具。为了和客户沟通， 就向客户开放了部分系统。公司创始人和总裁杰森•弗瑞德（Jason Fried）解释说，在他们自己意识到之前，已经做出了一套基于网页的应用。又做了4个月，他们把软件转换为称作Basecamp的服务。 Basecamp发布于2004年2月，很快在类似Flickr和Google的Gmail等新Web富应用天堂中名列前茅。

Basecamp只是这家公司花一年多时间投入少量程序员做出来的一系列值得注意的小而精的产品之一。Basecamp之后是Ta-da List，用于保存和共享待办事项（及类似事项）列表。几个月后推出了Backpack，它允许用户保存和共享便签及文件。每种产品都可靠并易于使用，而 且都是精心设计的。每种产品通常也都只包括少量新特性。例如，Basecamp就有一些精巧的电子邮件功能：和其他服务和程序一样，也可以设置邮件到达提 醒——还可以从另外的计算机或手机等移动设备向Backpack网页发送邮件，邮件文本就会在页面上显示出来。

我刚开始使用Backpack时，是用来保存本书的零散调研笔记。2004年秋天在一个技术大会上偶遇弗瑞德，我问他37 Signals怎么能在如此之短的时间内做出这么有用的软件。他大力鼓吹自己的方法——他公司开了个名为“制作Basecamp”的训练班，将所用原则做 成了一套PowerPoint幻灯片——而且逼着我在酒店大堂里听了45分钟关于其方法论的概要介绍。

首先，37 Signals只有一位开发者，所以就避开了布鲁克斯法则的泥沼——就像米奇•卡普尔最初做Lotus 1-2-3那样，当时也只有乔纳森•萨赫斯（Jonathan Sachs）一位程序员。开发者之间的协调不成问题。37Signals唯一的开发者戴维•海因梅尔•汉森（David Heinemeyer Hansson）住在丹麦，就连这似乎也不成问题。弗瑞德说，在大多数公司里，地理上的分隔会被看做是严重问题，不过时差却让他们真的只有区区几个小时可 以讨论，所以他们会高效利用这点时间，跟着开发者们就能平心静气地写代码，不受干扰。

照37 Signals的做法，约束是朋友。“约束是打造伟大产品的关键，”弗瑞德说，“约束产生创意。如果有人说，给你全世界的财富，让你做任何想做的东西，那这东西多半永远发布不了。给我一个月就好！”

实用最小主义的基础——Web应用

37 Signals生产优秀软件的另一关键要素是紧抓Web应用不放。所有东西都通过网页浏览器运行，所以程序可以在任何能运行浏览器的计算机和操作系统上工 作。版本更新可以很容易地在运行服务的服务器上做到，用户无须下载和安装更新。汉森还热衷于Ruby，一种面向对象动态编程语言。Ruby近似于 Python，不过较少为人知，汉森发现它简化了自己的工作。最后，37 Signals的方式还避开了编写规约的环节；相反，一开始就做用户将看到的详细网页。这些页面设计成了规约。弗瑞德说，他的团队很少会长时间争辩页面上 的每个词、按钮和方块。

37 Signals只做小程序，不做野心勃勃的新平台或应用程序框架。但在打造Basecamp的过程中，汉森还写了一些有用的创新代码，改善和简化了所有 Web应用在保存和获取数据时都要执行的细节基础操作。Basecamp发布后，他和37 Signals决定把这部分工作拿出来，作为一套开源平台发布，名字是Ruby on Rails。这套将被命名为Rails的框架在某种程度上通过约束程序员的可选手段使得编写Web应用更为简单。“灵活性被过分高估——约束才是解放，” 汉森说。Rails也具备实现AJAX风格增强界面的能力，这种新界面风格让基于Web的程序足以与桌面应用抗衡。

37 Signals从Basecamp中抽出Rails的同时，还从Basecamp的经验中归纳出一套设计哲学，体现为一系列小警句：“精简代码。”“拒绝 在先。”“找对人。”“与其做半成品，不如做功能减半的优质品。”这些短句是为了通过幻灯片快速演示，不过合起来却是一整套软件开发方法——姑且称之为实 用最小主义。它也许不能满足鼓舞了如此多程序员的改变世界之瘾。你也可以批评它是锋芒尽失的表现。它看似不适用于那些别无选择只能做大的软件。用程序员们 的话来说，就是“配不上”。

Google也实用最小主义

不过依据37 Signals一直以来的跟踪记录，有个最大的推荐理由：它的行事方式看来的确有效。类似的方式在一家规模更大、也更为著名的软件公司中已经获得空前成功 ——甚至可以不太夸张地说，获得了改变世界式的成功。Google遵循一种听起来很像杰森•弗瑞德推崇的那种软件开发哲学，成长为规模达数十亿美元的巨 兽，并且开始挑战微软：每个新项目专设一个小团队，开发期限紧迫，做出目标集中的网页产品，然后再根据用户反馈和领域经验加以逐步改进。Google也让 开发者把五分之一的工作时间花在个人项目上。这“20%时间”的劳动成果可能会变成很酷的新产品——或者不会。不用担心，Google安抚员工说：尽管开 干，挠你自己的痒处。

Google因打造了工程师天堂而获得赞誉，算法称王、编码者说了算。那些有幸受雇于Googleplex的人——包括安迪•赫兹菲尔德和2005 年加入的Python发明人圭多•范•罗萨姆——暂时在这里逃离了软件时间的困境。Google做出过一些半成品，但无人能质疑其成功的价值——从最初的 搜索引擎到基于关键字的广告业务，以及流行的新免费电子邮件服务。

实用最小主义在Google用得很好。而且它现已成为一家声名显赫的公众公司，面对着跟上成长步伐和找到新收入来源的压力。对于许多人来说，看似 Google正在一手制造硅谷的新泡沫。如果它在这种情形之下坚守其方法论，想出如何在不变慢、不变笨的前提下成长得更大，那么它将是软件业历史上独一无 二的。

打印  |  类别：设计思想  |  源地址