谢罪销毁和skin in the game

这两期的币乎周报中，最后一块都会有开发团队被发现bug，造成用户体验、功能异常、服务中断等等问题的，公示销毁一些团队持有的key，以示惩戒，以儆效尤。

这个真是一种创新举措，让开发团队能更加沉浸入对产品的稳定性、功能性、用户体验度的把控上，让所有的开发人员skin in the game，在产品的生命周期中休戚相关，就像对待自己最珍视的东西一样对待自己的开发代码，产品质量。

现在普遍的软件开发问题

我碰到过很多的软件开发公司，有大型的、有手工作坊式的，有软件成熟度cmm5认证的，也有野路子出身的，合作开发了很多软件系统、平台。总体来说，软件产品质量的层次都差不多，就算是cmm5认证的企业，软件的稳定性和bug的管理，也就是比野路子的好那么一点点。

因为中国的软件企业，cmm5认证是一回事，认证完了，有没有按照cmm5的软件开发要求来把控质量，就是另外一回事了。我看到好几个企业，做cmm5认证时，确实做了巨量的文档，流程，约束，只是等把认证证书拿到手，这些散布在全国各地的项目组软件开发工程师该怎么写代码，还是怎么写代码，测试更是一塌糊涂，完全没有软件质量控制。

究其原因，软件开发本身是一项巨复杂系统（指大型软件），需要参与的程序猿很多，在事实上造成了复杂度密集，问题排查困难、责任追究更困难。

再有，如果软件公司的老板或者责任高管不建立bug责任追究的机制，用户单位也没有严密且严格的责任追究要求，就会很容易陷入bug重复出现，问题重复发生的恶性循环。其本质原因是，作为第一责任人的码农，没有skin in the game，没有把自己的切身利益和自己的开发代码严密的绑定在一起，一荣俱荣、一毁俱毁。

雪崩的时候，没有一片雪花是无辜的，也就是说，没有一片雪花应该完全承担责任

现在程序猿和代码之间的普遍关系是，代码之间强关联，责任弱关联。就像形成了一股默契，有问题bug，大家会去一起解决，只有有没有新的bug，等问题出来再说。具体bug是谁的责任，很难说，网络不稳定、接口不稳定、数据有异常、规则有漏洞等等等等，程序猿基本上可以找一堆的理由，让代码纠察员最终丧失一直追究下去的勇气和能力。

我们也在合同约束过，发生一次bug故障、服务中断，经确认是代码引起的，对开发公司实施扣罚，并责成开发公司对责任码农实施扣罚工资。

但是事实上，这个措施很难执行下去。一方面进入运维期后，很多开发期的代码bug才会暴露出来，而开发费用已经不在甲方了，另一方面，这些码农还是开发公司所倚重的，不敢轻易惹毛他们，否则，现在码农还是比较吃香的，马上撂挑子到下家去了。于是，这个责任根本就追究不下去。

谢罪销毁好办法

当区块链金融普及时，是对任何利益相关的产品实行责任追究的好工具。一个产品的有效生命周期中，按照使用比例，由用户逐步释放token代币，产品发生问题，按照智能合约的判定，扣罚或者销毁token。

古代巴比伦王国的汉谟拉比法典规定，建筑师建造的房子倒塌了，把房主的儿子给压死了，建筑师的儿子要偿命。延续这种利益攸关的精神，我们这个时代，软件产品的质量才会和收益真正密切相关，发生一次代码bug，开发的码农账户上的token就会被自动销毁切肤之痛的一部分，无论他是否还在这家公司。

这样的方法，还怕软件产品的质量不大大提高么？

币乎开发团队给软件质量把控上给出了一个很好的办法，如果大范围推行加上区块链token应用，会给整个软件行业的质量提升带来巨大改变。

不过，我们也看到，币乎实际销毁的key从总体数量来说，还是微乎其微，和团队激励的key相比。既然迈出了第一步，建议加大力度，一定要销毁让程序猿有切肤之痛的key数量，才能真正起到惩戒后进，激励先进的作用。