• Feeds

  • InfoQ 8周年的一次活动

    不是所有人都注重生日的仪式感,一个人发展顺利时候,庆祝生日固然心情愉快;发展遇到瓶颈,又或者到了而立之年不惑之年,还没有和榜样一样步入人生巅峰,生日的仪式会无形中变成压力,暗示你时间的飞逝。

    InfoQ自进入中国以来,一直在专业领域有良好的口碑,8年在技术传播方面作用不可估量,InfoQ的大会参会人员越来越多,演讲的质量尤其是本土讲师的效果越来越好。上周末InfoQ举办了8周年庆“坚持与梦想”,活动选在中关村创业街,也是挺应景。据说整个2014年,大约有200个团队在这条街上拿到接近10亿人民币的投资,不过那是另外的故事了。

    活动安排是周六下午1点开始,北京正是一个雾霾的沙尘天,提前几分钟到,算是比较早的。接着到来的是守时没吃午饭匆匆赶来的的左耳朵耗子。几年来每次见到耗子都能听到一些惊心动魄的故事,在他还在Amazon的时候,一次过去交流,听他讲述由于某条微博而被网友人肉的故事。几年后在QCon分享,故事则变成了绩效3.25的历程,今天则围观了大牛介绍最近在微博种种吐槽背后的前因后果,火气也是有原因的。

    infoq anniversary

    活动是邀请制的,大部分嘉宾是历年QCon活跃面孔,包括一些平时已经不太露面的社区传奇人物,大约2点才正式开始。开场则是霍泰稳(Kevin)介绍了InfoQ中国8年的历程,并且选了一些行内的创业公司,讲述他们与InfoQ的关系以及一起成长的故事。Kevin去年创建了极客邦科技,将InfoQ中国的业务收购了,因此如果大家最近参加InfoQ各种活动,会留意到背后是极客邦的logo。

    后面是InfoQ社区编辑的分享,自称“技术圈交际花”的@程显峰-Mars,以前参加MongoDB的会议时候经常看到他的身影。MacTalk池建强老师,讲述8年中,从一开始在InfoQ社区翻译文章到成为InfoQ中国的顾问合伙人,Kevin及InfoQ背后有个神秘的顾问群(包括著名的微信三贱客)在一直在出谋划策鼎力支持。另外一位青云创始人兼CEO黄允松(Richard)分享了他创业及在IBM工作时候的一些感悟。Richard虽然也是个技术人,但是脱口秀的能力挺值得学习,不知道是在IBM做专家还是最近做销售练就的口才。在台下时,又听他爆料说青云2014年烧了几千万不过只亏了几百万,这在云平台这种投入非常大的公司已经非常不易了。另外说青云的系统目前重点不是互联网用户,不过未透露原因。

    中国合伙人中佟大为老师扮演者,真格基金和新东方联合创始人王强老师(电影中泡洋妞那位大哥)精彩分享。新东方老师的演讲能力确实一流,只记下了 他谈到分享的真谛,“每一次上台,你都要当做第一堂及最后一堂来讲”,只有这样的心态,演讲才会真正让自己及听众满意。

    压轴的是社区领袖代表传奇人物霍炬,自称”自己做的事情都失败了,帮别人做的事情都成了”,讲了他最近几年做的系统与老外PK的故事,这几年完成的几个系统,包括在国内打不开的纽约时报中文网。离开北京之前,霍炬在圈内也是一个传奇人物,据说当年许多进京的朋友都会去找霍炬拜山头。不知道几年后从加国回来,再次漫步在中关村创业街头,看着周围都是陌生而又年轻的陌生面孔,是一番怎样的体验。几年前在华东某个活动上,曾经碰到霍炬的太太西乔,尽管看过无数期程序员杂志西乔的漫画,被美女问到是不是在哪儿见过时,被我肯定的回复应该不认识,又被霍炬糗事重提了。

    台下也见过一些朋友,有些也是三五年不见的,但由于社交网络让大家保持连接的缘故,感觉也并不陌生。活动结束时,外面的沙尘已经散了,北京又出现了难得的蓝天。

    软件领域的Reinvent

    苹果经常喜欢用“Reinvent”这个词,用在硬件领域确实高大上。但在软件领域Reinvent大多时候是个贬义词,软件领域上下游结合及相互依赖非常紧密,没有哪个团队甚至公司能封闭的完成所有事情。因此重新发明这件事情在软件领域并不吃香,一个新的体系在小的团队通常会自生自灭(尽管途中可以获得一些荣誉),剩下那些硬撑的项目则会让参与人员痛苦不堪。

    比如各厂定制的各种百花齐放的框架,运作几年之后,核心系统越来越臃肿,随着人员的更替能深入了解内部的人也越来越少,改进的动作非常迟钝。但大量的上下游业务服务又需要依赖这些系统,新来的人需要较高的成本熟悉整套系统。问题丛生,但是离开又需要付出极大代价,于是就成了一个鸡肋。如果使用方牵涉到多个部门,更不会有人站起来说将这些定制系统废弃或迁移。

    但这个现象在计算机语言领域则是一个例外。一门新的语言,不喜欢的人可以不用,而且大部分开发团队是随大流,不会选用小众语言,所以新语言领域已经在搭建的哪些不成熟的系统也不会给业界带来麻烦及痛苦。少量情况下,极客会心爱的小众语言搭建的一些系统,但根据观察,这些系统通常会随着极客的离职马上会被用主流语言重写替换。因此在新语言领域,可以用更轻松的心态去重新发明各种组件。

    一门语言出来之后,复用另外一种语言的模块与组件不是最佳方案,理想情况会选择构建自己的函数库,框架,开发工具,测试工具,代码工具,性能调优工具等。在新的语言出来的早期,这些领域一片空白,踏入这片领域的人会有新大陆淘金的感觉,随便写点东西,很快可以找到市场。

    在一个新的语言重写一些别的语言已经完成的项目,尽管这不是什么伟大的发明创造,但参与的人往往更快的取得了成绩并且赢得了尊敬(相对于在“主流”语言拼搏那些人)。我也曾经思考过这个现象。技术人的价值观虽然很多元化,但是有两点却几乎是共通的,一是工程师动手创造带来的成就感,二是感受创造的东西给所在环境以及业界带来使用价值的成就感,不管这些创造是原创的还是山寨。因此在很多领域如搜索、广告以及更基础层面OS、Database、Language总是有乐此不疲工程师重新去建设,因此在语言层面的重新建设就变得容易理解了。

    更深层次的来看,在语言层面的基础上,重新去构建一个生态圈,从社区的角度,不只是重新克隆一个新的版本,工程师会考虑以往的经验及教训,重新设计重要的单元,以带来性能上的提升及使用方式上的改进。比如这几天写一个Go语言的小程序,看到Go的社区在配置文件方面的思考及重新选择。配置管理在Java领域大多是XML一统天下,尽管其可维护性较差,但由于历史原因,工程师很难去另起炉灶。

    当然在新OS领域重新创造的机会就更多,但是这种情况较少发生,一个新的OS生命周期会延续10年或更久。一些大公司的开发平台生态圈也有类似的这样的机会,不过大部分情况下格局会小很多,也会存在更大的不确定性。

    团队的技术形象

    当一个app不好用时候,用户会说团队的产品不行;当系统可用性有问题时(比如访问慢或频繁宕机),用户会说这个团队技术不行。

    发生频繁宕机并不常见,宕机通常会由程序bug或者访问压力过大引起。bug最终会被修复;在不过分在意成本的情况下,访问压力最终可以用硬件来扛住。另外系统升级及功能变更也会带来可用性与稳定性的问题,但大多数系统会最终相对稳定下来,大的变更会越来越少,系统也会趋于稳定。

    技术成本的控制通常不是一个很紧迫的问题,一方面公司的业务模式也不是靠省服务器做出来的,其次技术团队可以通过投入时间去优化改善来降低成本(但大部分团队更愿意将研发资源投入到新功能开发上去)。因而通常只要达到基本可用,则成本合理性问题不会得到充分关注。另外成本也很难直接对比,一个公司比另外一个公司服务器少些,但是各自功能场景有差异,没有直接可比性。因此较难从技术成本合理性角度衡量某个团队技术好不好。讽刺的大部分现实是,只要系统基本可用,则会被视为一支有战斗力的团队;如果能达到一定体量(虽然不是技术团队直接带来的),那则会被视为超强的技术团队。

    软件质量在大部分公司走不出测试或者“质量保证”部门,很少有团队会认为步子不够快是由于软件质量问题造成。开发效率同样没有直接可比性,“努力”有时候会掩盖一切,朋友圈时常会看到这样的总结,“虽然走了一些弯路,但兄弟们加班加点将进度追了回来,感动……”。比软件质量问题更糟糕的是业务方向的不确定性,方向不确定带来的消耗比软件质量的问题更大,走错方向导致一两个月努力泡汤的事情也很常见,因此不是最短板的软件质量的重视通常就无从提起了。

    隔洋对岸则有一些技术主导的公司,Mark Zuckerberg曾说过,Facebook在早期时,非技术岗位如HR及市场也招聘有技术背景的人担任。这些公司尽量招聘最顶级的技术人才,这些人能够在公司中享受技术的乐趣。但这也只有平台级的公司才有可能。这些公司商业模式的门槛足够高,从而有持续的利润来支持这一愿景。而剩下绝大多数公司,需要首先去考虑生存的问题,这也很正常,头部的公司如果失去垄断地位,也马上没有机会去维持纯技术形象。

    技术行不行是一个很无力的目标,技术很强的团队未必能改变世界,不强的团队很多时候也生存得很好。业界很多业务模式短板并不在技术上,更混乱的是,出现技术问题有时反而被当做PR事件及段子去炒作。当然,在技术较差的团队,软件质量及技术创新无从谈起。处在风口的猪,也会遇到前文所说的重复踩进同一个坑的无力感。