外刊IT评论今天抽风,发了很久以前的一篇博文的译文出来:《为什么我们不要.NET程序员》。本文一发,各种口水接踵而至。这篇文章实际上是《CEO Friday: Why we don’t hire .NET programmers》的译文,原文作者在发文后的两天的时间里不断的根据读者反馈对文章进行了更新和补充。但是遗憾的是外刊IT评论却未能翻译完整(不,不,你们不要指望我会翻译剩下的部分,我对此毫无兴趣。),这使得这篇很有闪光点的文章立刻变成了“孰优孰劣”的口水文章了。

看看中文翻译后的评论吧:

有一种人,自己写不出东西,就怪能写出东西的人使用的工具太先进

弱智文章

SB文章,还以为有什么高深的见解,完全是个自以为是的家伙。至多不过是了解了.net之外某一些东西,对自己完全不了解的东西大放厥词还放出优越感来了。

俺作为一名.NET程序员,鉴定结果为,“此文纯属标题党”,一笑而过~~~

我对留下这些评论的程序员感到悲哀……

我们的团队也有着大量的.NET工程师,我每天与他们共处。他们中间有聪明的、优秀的、稳重的工程师;也有躁动的、浮夸的、随意的编码人员。他们能够产生符合设计规范和要求的代码和系统;也会在不经意之间向系统引入致命 bug 而导致生产环境的崩溃。他们其实与依赖其他技术架构的程序员并无多大的不同。

Continue reading »

 

这是典型的“死Coder责任制”和“QA无用论”合体。大家仁者见仁、智者见智吧。个中道理还是得自己参悟啊!

原文在此:http://blogs.forrester.com/mike_gualtieri/11-02-17-want_better_quality_fire_your_qa_team,原作者是Mike Gualtieri,一位应用开发和部署专家。

————翻译分割线———— Continue reading »

 

刚才看到 Fenng 写的这篇博文:大技术团队的危险性。其中的一些东西,确实有一些感触。

维基百科上对于“团队”的定义是这样的(http://zh.wikipedia.org/wiki/%E5%9B%A2%E9%98%9F):

“团队由若干独立成员共同组建,有临时与长期之分。团队要为某一共同目标而奋斗,这需要团队成员贡献各自不同的专业特长。对团队的管理不同于上下级关系的管理,是横向的交流与沟通而不是纵向的命令与服从。”

虽然不是一个十分正式的定义,不过能说明几个问题。

  1. 团队不是一个人在战斗。
  2. 团队有统一的目标。
  3. 团队成员一定有分工。
  4. 团队的工作方式是合作的,而不是管制。

团队成员不光可以是个人,还可以是一个紧凑的组织,部门甚至公司。成员间进行平等的沟通、交流,相互支撑最终达到一个确定的、统一的目标。

由于沟通交流是平等的、横向的,那么就意味着任何沟通都是点对点的。当团队成员增加时,沟通的难度也就加大。

听起来有点像早期没有交换设备的点对点电话。在只有2个端点时有1条通信链路,3个端点就增加到3条,4个端点就增加到6条……那么对于一个有 n 个成员的团队,每个团队成员就需要有 n-1 个沟通链路。当沟通链路数足够大时,整个团队的人都在忙着沟通,而不是真正进行工作。当超过临界,沟通链路超过单个成员所能承受的极限时,为了维持团队正常的运作,有一些沟通链路会被忽略。一些工作关系相对疏远的成员不再进行沟通。这时从行政架构上虽然还是一个大团队,但是这个大团队已经不复存在,由若干个自然形成的小团队取而代之。

4-5个人组成了开发小组。4-5个开发小组组成了技术组。技术组、客服、市场……组成了项目组。项目1组、项目2组……组成了项目部……自最终稳定的团队结构是树形的,是分层的。站在每层去看,每层的团队都是小团队。当某一层上的团队开始有大团队出现时必然会有新的层次出现,将大团队重新划分为小团队。

这或许就是“无为而治”的道理吧。

硬是要将这种很有美感的、自然的组织架构重新排布,徒增本不需要的沟通链路,那么团队的结果或许跟瓦沙一样最终沉没。

© 2011 Some reminiscences, some memories Suffusion theme by Sayontan Sinha