软件开发，在保证功能完成之后，首要的一件事就是，确保软件不会给客户带来破坏。因此除了敏捷开发以外，我们主要做了三件事情来让码农不要在开发的时候太分心搞别的。
第一件事就是你做了一个关键的设计之后，会有一个负责security review的小组来看你的文档，问你问题，根据他们的专业经验指出软件哪里可能是会被攻击的薄弱环节。举个例子，你用了XML做配置文件，如果用户偷偷给你换了一个破坏过的XML，你的程序就会挂。一旦程序进入挂了的状态的时候，是很危险的。如果你试图恢复它然后继续运行，你就得考虑大量的细节，来把你的软件从错误的状态恢复到正确的状态。中间稍有不慎就容易被攻击。所以我们都鼓励说，一旦发生了这些不可逆转的破坏，就让程序自己出dump然后自杀。当然具体到XML这个例子，我们还有xsd文件，用Windows自带的MSXML组件来实现验证一下，所以还算是个小事。JSON就没这个福利了。
第二件事情就是，我们的环境搭得特别科学。譬如说你开发SQLServer2014，那你还要给SQLServer2008打补丁。2008打补丁的时候用的SDK和开发环境可能跟2014有巨大的区别。所以我们有一个Build Team，写了几万行的perl和bat脚本，来使得我们可以做到说，我们只要从2014的branch切换到2008的branch，这些工具就自动变了，譬如说cl.exe就从新的版本指向了旧的版本，库啊什么其他的乱七八糟的也是。如果你刚好用不上Visual Studio的话，只要你把代码从Source Control上搞下来，运行他帮你建立在桌面上的一个快捷方式，就可以打开一个cmd，里面的环境都配置好了， 而且不会污染别的cmd 。那我们就再也不怕手忙脚乱用错工具来开发导致出现更多问题了。一个人有可能要同时在不同的版本上干不同的事情，因此这是很重要的。因此我们也会把大量的二进制文件checkin进去，因此很多组尝试使用git最后都失败了
第三件事情就是制度的问题了。产品狗在我们这里，责任很大，权力很小。原则上产品狗是管不了我们的，我们之所以听产品狗的话，是因为我们跟产品狗都有相同的目标——把软件做好。所以每当产品狗做了一些奇怪的决定的时候，我们可以很容易的拒绝他。他为了完成他们自己的工作指标，要么就要来说服我们，要么就只能改自己的决定了。因为产品狗和码农之间没有达成一致从而导致软件没按时完成的，产品狗具有很大的责任。我们还有专业的测试团队。测试团队的权力不小。譬如说产品狗提了一个需求，测试可以跳出来说这个功能会给测试带来无比的困难，从而拒绝产品狗的决定。因此产品狗的每一个决定，首先要保证可以被科学的实现出来。当然产品狗自己通常可能不知道什么是科学，所以我们要通过不断的打他的脸来让他明白，什么是科学。