Worse is better? 转自robbin

来源:互联网 发布:软件助手 编辑:程序博客网 时间:2024/04/30 12:31

Worse is better?

entrepreneur

Worse is better 是一个很典型的观点,这个世界上充斥着“Worse is better”的东西:VB绝对是个垃圾的语言,但是他战胜了Delphi;IE绝对是个垃圾的浏览器,但是他战胜了Netscape,现在也一直领先着Firefox;MySQL的数据库特性绝对不如PostgreSQL,但是市场占有率遥遥领先;MacOSX操作系统的优秀毋庸置疑,但是Windows是绝对的霸主。

然而这种观点的逻辑性却很诡吊,因为他的隐含意思大约是这样的:XXX就是再好,也不如YYY在市场占有率大/商业成功/影响力广,所以XXX就是worse的,YYY就是better的。换句话来说就是:成王败寇,成功了就是好东西,不成功了就是坏东西。

什么是“非工业主流”编程语言。

我不知道如何下一个严格的定义。简单地说,就是不被绝大多数程序员所使用的编程语言。

看看tiobe的语言排行榜,你可以了解我在讲什么。Java、C、VB、C++和PHP占据了70%的份额,它们是当之无愧的工业主流语言。而 Ruby尽管连连升级,排名13位,份额也不过是0.804%,Lisp/Scheme连连下挫,目前仅为0.586%,如果你仔细寻找,在The Next 50 Programming Languages的标题下,Erlang,Lua,Scala缩在角落里,这些“可怜”的语言当然是非主流的。自然,你不不太可能认为PL/SQL 、 Visual FoxPro、 VB.NET和Lisp、Ruby、Erlang、Lua是同类,我也这样想。

或许你和我曾经或正在感到非常振奋,那些你我日常的编程语言高居前列,并引以为豪。但是事情并不是完全象我们想像的一样。

编写程序需要乐趣,很难说工业主流语言能够提供你更多的乐趣。我所知道的很多程序员在白天忙乎完手上的Java,C++工作后,晚上会带着一种神秘的快感摸索一些可能自己一辈子也不会用于谋生的语言。

当然,这可能是厌倦造成的,但是当你发现一个苦思冥想、或者需要n多语言规则、框架、n多所谓的高深理论解决的问题,在另外一种语言中是最最简单的一个特性,恐怕这种懊恼的感觉不是可以轻易描述的。譬如,当你天天为C/C++的内存释放绞尽脑汁的时候,当你为垃圾收集在Java的出现而欢呼的时候,你是否知道30年前,那已经是Lisp的一个标准构造了。当你天天面对着无穷无尽的并发要求,纠缠不清的哲学家吃面头皮发麻的时候,你可能很想知道Erlang 20年前就让极大规模的并发和可靠性处理变成小事一桩。

编写程序还需要创造价值,一个非凡的产品在获得巨大利润的同时,更会带来一种心底而生的自豪感。如果要担心工作的问题,那么主流语言是你必不可少的谋生工具。但是如果你从头建立一个公司,希望用有限的资源和人力制造出强有力的产品,一个与众不同的产品,那么你需要秘密武器,这些武器是什么呢?当然可以有很多,但其中最有杀伤力的武器之一无疑是编程语言--高生产力,适合某一领域的非工业主流语言。这种例子并不罕见,例如: 
Beating the Averages 
Making Money from Erlang 
google

也许,你喜爱的语言被成千上万的人使用并不是那么令人自豪的事情;自私一点地说,缺乏同伴或许能够带来更多的乐趣和财富

我想表达的一种观点就是: 一个worse但是商业成功,被大多数人接受的东西并不必然成为适合你的东西:例如Mac确实不如PC普及,但是Mac适合我,我用起来很爽,工作效率很高;IE浏览器确实很普及,甚至很多网站专门为IE设计,但是我用chrome很爽,工作效率很高;php很普及,但是我用rails的开发效率非常惊人。

Erlang之父Joe Armstrong用Erlang这种非主流做产品开公司赚了千万身家,Rails之父DHH也用rails这种非主流做37signals赚了千万身家,现在开保时捷赛车做职业车手,就是potian本人,也用Erlang和Rails这两个非主流做视频监控软件,做出来一个纽交所上市公司。非主流究竟是让你不耻于使用的东西,还是能够给你带来成功的秘密武器呢?

小公司应该组建什么样的研发团队? 大规模普通水平普及型编程语言团队,还是高效率高生产力小规模团队?我认为目前小公司唯一的活路就是高效率的小规模团队,这样的团队才能充分发挥小公司灵活创新的特点,才有可能在某些方面战胜大公司,也才有可能在人才竞争方面胜出。

小公司如果想组建大规模普及型编程语言团队,往往是个看似容易,实则无法实现的泡影:一方面普及型编程语言招聘需求旺盛,跳槽频繁,你比大公司在人才方面的竞争力弱,不可能招聘到很多合适的人才;另一方面小公司上规模的研发团队,管理上的挑战非常大。我们都知道,研发团队每增加一个人,沟通成本都指数级上升,规模到了一定的阶段,就必须动用严格的KPI体系,而不是靠个人激励来管理研发人员,而一旦制度化管理研发团队,隐性的人力成本浪费就是惊人的。最终结果就是你的研发团队规模越大,整体生产效率越低,而整体生产效率越低,你就被迫越扩大研发团队的规模,最终陷入恶性循环。

JavaEye的实践可以证明,高效率小规模团队的生产力可以超过大规模普通研发团队。其实我也很想有大把的钞票,很好的公司品牌,牛人们纷至沓来的那种感觉,但是那都是幻觉。我们要以弱胜强,以少胜多,就必须选择自己build团队,自己培养人才,采用高效率的秘密武器。

原创粉丝点击