345    这说明了什么？

346    只要不损失效率，就不要对丢弃一些功能而举棋不定。

347    圣-埃克苏佩里（当他不写作经典儿童书籍的时候，是一个飞行员兼飞机设计师）曾说过：

348    13.´完美（的设计）意味着没有东西可以再被加入，而是没有东西可以移除”

349    当代码变得高效又简洁的时候，就可以说是走上正轨了。

350    在这个过程中，fetchmail有了自己的特设，脱离了前代的popclient。

351    到了该换名字的时候了，新的设计和老的popclient相比，更像是sendmail的搭档。

352    二者都是MTA，不同的是sendmail是向外投寄，而新的popclient是接收转发。

353    所以，开工两个月之后，我把它更名为fetchmail。

354    在这个将SMTP转发加入fetchmail的故事中，有一则普遍的经验。

355    那就是不仅调试可以平行展开，开发和（也许这很令人吃惊）探索设计空间同样也可以。

356    当采用快速短周期开发模式的时候，开发很可能成为针对原有的冗余设计或开发观念的一个特殊´调试-修补”环节。

357    即使在更高层次的设计中，能有许多协作开发者围绕着你的产品设计空间随机游走也是很有价值的。

358    试想一下，一滩水是如何找到排水口的，或更贴切一点，一群蚂蚁是如何找到食物的：实际上就是在分散搜索之后，以一个可延伸的通讯机制加以协调。

359    这很管用，就像哈利·豪切斯和我一样，一个同行之人很可能在你身边开启宝藏，而你只不过是太过专著才一叶障目罢了。