There is a silver bullet or no silver bullet
link：No Silver Bullet. There is a silver bullet
Brooks在"No Silver Bullet."借用将软件开发过程中的复杂性，困难性比作传说中在月圆之夜去袭击人类“人狼”，普通子弹都伤不到也打不死它，只有一种用银子作成的”银弹“才能杀死他。并得出结论：
没有任何技术或管理上的进展，能够独立地许诺十年内使生产率、可靠性或简洁性获得数量级上的进步
这看上去有些悲观，初次看也是难以理解，只有“银弹”可以解决问题，而十年之内有找不到银弹，那得出的结论就是这个问题无解。在There is a silver bullet 中，作者用托勒密扩展的亚里士多德宇宙学模型（宇宙以地球和人类为中心）做了说明，我们的以流程为中心的软件开发模型和宇宙学模型一样根深蒂固，我们可以对模型进行调整来消除一些差异或者偏差，但是没有想日心说这样一个性能的范式提出来简化这一切，要靠程序员不断订正来克服当今软件开发是不可能在数量级上取得突破，所以需要一场变革。Brad J. Cox认为我们需要一场文化变革，
It was not a new process, some whiz-bang computer or programming language for computing epicycles more efficiently. It was a cultural change, a paradigm shift, a "mere" shift in viewpoint as to whether the heavens rotate around the earth or the sun.
而这场文化革命，或者说这个“银弹”是可重用的软件构件。
没有银弹，Brooks在《人月传说》中说的很明确，也很有道理，看似悲观，但是是事实。我们本科的程序基本都是为自己使用而构建的，没有开发中的问题，始于实现而终于实现。在软件开发这里，开发的模式，就开发流程一个整体实现不可能，划分阶段又是模糊的，而且每个项目，不可能用单一的方法，屡试不爽。有各种方法综合运用，才是解决之道；而一到综合运用，就和开发经验等多种因素有关，所以这个杀死狼人的终极武器，还是不能被开发出来，适应一切。在有银弹中提到的软件构件的可重用，我觉得这也许是铁弹，铜弹，因为“没有银弹”说的是不能获得数量级上的进步，没有说不会进步，在alpha阶段，我们的程序有些是仿写的，有些是复用的，而用julia的Flux本身不就是在复用性的一种体现吗？所以如果按照我对“复用性”的可能“错误”的理解的话，还是没有银弹。
A BIG BALL OF MUD
A BIG BALL OF MUD is haphazardly structured, sprawling,
sloppy, duct-tape and bailing wire, spaghetti code jungle.
产生大泥球的缺点是：局部与全局，重要与不重要没有了明显的界定，所有的信息看上去都很重要，可重用和修复性很难得到控制，系统的整体结构可能永远不会很好地定义。
原因是：用户的需求或者编程的要求是在不断地变化的，程序员解决问题的代码是一次性代码等等诸多原因。
改进是：You need to deliver quality software on time, and under budget.
Therefore, focus first on features and functionality, then focus on architecture and performance.
在alpha阶段开始的时候，还好我们的有过讨论，确定了框架，再加之有指导性的开展工作，我们没有开发出大泥球。我们将数据处理，bi-lstm模型，main框架，evaluate四部分拆分来实现，每天有讨论，避免了我们开发出大泥球，我们上下接口是商量好的，如有变动，双方线下也会调整好。明确的分工在需求和编程要求变化后，可以及时的调整。我们的系统没有变成大泥球的也有一个原因是，我们的任务偏向学术方向，用户是潜在的，或者我们就是用户本身，需求规定好之后不会变化。但是我们模型错了之后，就有点像泥球啦，每个部分似乎都有出错的可能，而且几个模块内部的实现也有混乱。也许是A BIG BALL OF MUD的理解没有get 到，或者我们的项目julia for AI本身的选题避开了泥球中的一些问题。
CatB – Cathedral and the Bazaar
CatB – Cathedral and the Bazaar介绍了教堂和集市两种开发模式：
The Cathedral model, in which source code is available with each software release, but code developed between releases is restricted to an exclusive group of software developers. GNU Emacs and GCC were presented as examples.
The Bazaar model, in which the code is developed over the Internet in view of the public. Raymond credits Linus Torvalds, leader of the Linux kernel project, as the inventor of this process. Raymond also provides anecdotal accounts of his own implementation of this model for the Fetchmail project.
教堂模式注重版本的更替，一个开发团队负责一个版本，源码团队内部共享；而集市模式是代码开源给公众。
我们的开发模式符合集市模式，源码公布在github上, 我们有alpha和beta两个版本，但是beta是在alpha的基础设置上进行改进和完善，我们的开发团队只有一个，期间也只发生过人员的流动，所以我们的模式更符合The Bazaar model。
方法的好和坏
link The Rise of Worse is Better
Is Worse Really Better
作者首先提到了”the right thing“的特点：
简单性：在实现和接口中，设计必须简单。接口的简单性比实现更重要。
正确性：在所有可观察的方面，设计都必须正确。一丝的错误都是不允许的。
一致性：设计不能不一致。为了避免不一致性，可以稍微减少一些简单性和完整性。
一致性和正确性同样重要。
完整性：实际上，设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。
简单性不可以过度地削弱完整性。
他又提到了“worse-is-better”的设计原则：
简单性：在实现和接口中，设计必须简单。相对于接口而言，实现的简单性更为重要。
简单性是设计中最重要的注意事项。
正确性：在所有可观察的方面，设计都必须正确。正确性的重要程度仅次于简单性。
一致性：设计不能过于不一致。在某些情况下，为了实现简单性可以牺牲一致性，
但放弃设计中处理非常见情况的那些部分比引入实现复杂性或不一致性更好。
完整性：实际上，设计必须覆盖许多重要的情况。应该覆盖可能出现所有情况。为保证其它质量，
可以牺牲完整性。实际上，只要危害到实现简单性，就必须牺牲完整性。如果保证了简单性，
可以牺牲一致性以实现完整性；尤其是在接口的一致性没有价值的情况下，。
可以看出来他是在强调简单性，我们的设计必须要做到简单，重要性高于正确性，必要时可以牺牲一致性和完整性。我们在实现的时候，过多关注的是正确性，简单性以这一点我们并没有去考虑，只是在实现过程中，自己会不自觉的注意。文中提到的为保证质量可以牺牲完整性这一点我是同意的，我们的需求可能不止一个，如果我们只完成了其中的几个，但是可复用性和可维护性高是完全可以的。比如我们就只是先把框架搭建起来，并没有去直接修改先把模型的准确率做到70%以上。我们首先要让我们的模型跑得通，其实还必须保证正确性，在一切基础工作都OK的情况下，修改模型或者训练参数来提高准确率。模型的简单性看似是不涉及，但其实用julia来实现NER本来就是出于简单性，由于julia的开发速度与python一样，运行速度又和c一杨，我们选择在julia上是实现，框架是很的清晰的。这篇文章我们可以借鉴的是，我们下来可以在接口上做的更简单，实现用到的数据结构可以在简化。