开发团队是一个整体，稳定的、沟通无碍的团队文化非常重要。好的文化氛围应该包括基于共识决策的开发模式、高质量的代码、代码审查，以及能让人放心尝试新事物或者快速失败的环境。Brian和Ben是Google的两位开发主管，他们在《极客与团队》书中列举了软件开发团队的典型不良行为，提醒开发者时刻保持警惕，并提出了一些实际的解决办法。
Brian和Ben指出，团队的注意力和专注力是最容易受到威胁的。团队规模越大，编写软件和解决有趣问题的能力就越强—不过这种能力毕竟是有极限的。要是你不去主动保护它们，很容易就会被害群之马引入歧途。团队最终会争论不休，变得心烦意乱、身心疲惫。所有人都会把注意力和专注力放到那些编写优秀软件以外的事情上去。
根据我们的经验，很少会有人故意干坏事（也就是存心捣乱的那种）。我们管这种行为叫作“钓鱼”，通常无视这种人就可以了。而大多数人在行为出格的时候，要么是没有意识到自己过分了，要么就是根本不在乎别人的感受。无知和冷漠其实比蓄意更严重。
他们列举了一些典型的不良行为。
第一条就是不尊重别人的时间 ，总会有一些人搞不清楚项目的状况，他们的危害通常是浪费团队的时间。他们宁可不断地拿那些很容易就能找到答案的问题去骚扰整个团队，也不愿意自己花点时间去读一读最基本的项目文档、任务宗旨、FAQ，或是最近的邮件讨论。 这里有一个现实当中的例子：
我们在Subversion项目里就曾经碰到过这样一个人，他把开发主论坛当成了自己每天报流水账的地方。查理实际上没有贡献什么代码，但他每隔两三个小时就会发布自己最新的异想天开。这样就无可避免地产生了很多回复，去解释为什么他的想法是不正确的，不可能的，已经在开发中了，之前已经讨论过了，或者是已经有文档记录了等。
更糟糕的是，查理甚至开始回答那些临时用户的问题，而且都答错了。这样，我们的核心成员只好不断地去更正他的回复。过了好久我们才反应过来，这位和蔼可亲的热心人其实是好心办坏事，大家被他牵扯了太多的精力。
第二条是自负，这里“自负”可能不是最恰当的词，Brian和Ben想要表达的是那种无法接受多数人决议，无法倾听和尊重其他观点，以及不愿作出妥协的人。这种人常常会重新挑起些早就已经结束（并且保留在邮件存档里）的讨论，仅仅是因为当时她不在场。这种人不肯去读存档，也压根不想去思考，她只会要求为了自己重启争论。她常常会就项目的前途作出极端的评价，声称除非按照她的思路走，否则失败就在眼前。
过分索求是另外一种不良行为。每当有陌生人跟你要求做什么的时候，一定要提高警惕。这样的人把所有的精力都用来抱怨软件功能不足，却不愿意自己动手作点贡献。有时候等天上掉馅饼的心态会演变成过激行为。在运营Google的项目托管服务时，Brian和Ben就遇到过这样的例子:
当时有一个项目作者要求我们封掉一个用户，因为他的所作所为实在是太讨厌了。这是一个开源的电视游戏模拟器项目，而这个用户最喜欢的游戏却无法在上面正常运行，于是他在问题跟踪系统里提交了一个口气相当粗鲁的bug报告。开发人员礼貌地解释了那个游戏跑不起来的原因，还告诉他相当一段时间里可能都没办法修复那个问题，结果那个人接受不了，每天都来骚扰开发人员。
他不断地提交同样的bug报告，里面充斥着各种不满，还在其他bug报告里评论说拒绝修复他的问题的程序员是个“蠢货”。尽管项目人员和Google管理员屡次警告，他的用词却反而越来越不堪。不管我们怎么努力去消除他的这种破坏性行为，他就是冥顽不灵，万般无奈之下，我们只好祭出最后一招—彻底把他封掉了。
除此之外，还有两种行为需要警惕：
幼稚或是莫名其妙的交流——这样的人不会用真名。他们常常会用一些幼稚的昵称，比如“SuperCamel”、“jubjub89”，或是“SirHacksalot”之类。更糟糕的是，这样的人往往会在不同的地方用不同的昵称—E-mail一个，即时消息里又是另外一个，可能提交代码的时候还有一个。更有甚者，你会看到他们用火星文、黑客语、全部大写，甚至含有大量标点符号的沟通方式！
偏执妄想——在上面的例子里我们看到，有时候不切实际要求会直接转变成对项目的恶意。我们无数次看到它彻底演变成偏执。当团队和访客的意见不一时，这种心怀恶意的人就会抛出某种阴谋论。要是太把他当真，去花精力和时间反驳的话就实在是太滑稽了。而且如果你已经建立起一条开放透明的沟通渠道的话，这种指控只会显得更加可笑，因为所有的谈话内容都是有公开记录的。我们的建议是根本就不用去理会这种指控。当这种人真的做到这一步的时候，你说什么都是没用的，既然这样干嘛还费这劲呢？还不如把时间用来写代码。
最后一条是完美主义。乍看之下，完美主义者根本就是无害的。尽管时不时地会有一些奇怪的强迫症类型的行为出现，但是总体上这样的人都是谦虚有礼貌的，而且愿意倾听别人的意见，看起来满是良好的本意。那么问题出在哪里呢？答案就是太追求完美会变得瞻前顾后、犹豫不决。现实当中的例子：
帕特里克是一名非常出色的工程师。他做的设计非常出色，代码和测试的质量也很高，人也非常容易相处。但是每当要设计新软件的时候，他就会无休止地调整、改进自己的设计。他从不满足，好像永远也不会开始写代码一样。尽管他对我们所面临的问题有非常好的见解和洞察力，但是团队里的其他成员最后都被折腾到不行。
这样下去就没法工作了，我们几个考虑了很久要怎么办。一方面，对团队来说帕特里克是巨大的财富；另一方面，他也妨碍了团队前进的步伐。每次我们打算开始编写代码的时候，他就会很有礼貌地否定我们的方案，指出其中只在理论上成立的潜在问题，而且都是一时半会不会产生什么影响的问题，不知不觉中他让我们整个陷于瘫痪状态。
Brian和Ben提出了一些实际的解决办法：
写一份明明白白的任务宗旨。这样可以随时保持专注，知道哪些是目标，哪些不是。
E-mail讨论要有礼仪。保留归档，要求新人研读，防范那些“嘈杂的少数人”。
所有历史都要有记录。这不单指代码历史，还有设计决策、重要的bug修复，以及过去犯下的错误。
有效地进行协作。利用版本控制，代码改动要尽可能的小，方便进行审查，扩大“公车因子”，避免出现领地感。
修复bug，测试，发布软件要有清晰的政策和流程。
降低新人加入时的壁垒。
依赖基于共识决策，在无法达成共识的时候也要准备好化解矛盾的方法。
