银弹
《No Silver Bullet - Essence and Accidents of Software Engineering》的作者Brooks主张并断言从这篇论文发表(1986年)开始计算的十年之内，不会有任何单一的软件工程上的突破，能够让程序设计的生产力得到一个数量级的提升。这是因为软件工程中的不可避免的几个性质：复杂性（complexity）、隐匿性（invisibility）、配合性（conformity）以及易变性（changeability）。Brooks将软件的开发分为accidental task和essential task，之前出现的高级语言、面向对象程序设计、人工智能等只是减少了accidental task的困难，而上述提到的几个性质都属于essential task，因此他才会做出如此断言，即软件工程没有“银弹”。
而《There Is a Silver Bullet》的作者Brad J Cox认为面向对象编程可以成为软件工程的“银弹”。因为他认为大量可以复用的组件（轮子）可以使得软件和其他制造业的产品一样，通过程序员（工人）按部就班的进行组装，而程序员们也不需要去关注轮子内部的东西，只需要知道接口怎么用就行。
就我个人而言，我更加赞同Brooks的观点，软件工程没有“银弹”，面向对象编程确实是一个强有力的工具，但总是要有造轮子的人才行，尽管现在什么轮子都有，也不能保证随着软件开发需求的不断变化，它们是否还能继续使用。因此我认为面向对象编程只能说在很大程度上缓解了软件工程的一些难题，并不能说正真解决了。
大泥球
所谓大泥球，是指杂乱无章、错综复杂、邋遢不堪、随意拼贴的大堆代码。毫无疑问，我的编译器就是，特别是生成目标代码时就是毫无设计，自己瞎写。
解决方法： 我觉得最重要的是一开始就要做好设计，多花点时间在设计上；另外，在代码风格比较好的情况下，一些大泥球还是可以挽救的；最后，在代价允许的情况下，我选择重构。
大教堂和集市
大教堂相当于软件工程的传统开发模式：软件只能由一组人开发，是封闭的、垂直的、集中式的模式；
集市是相对于大教堂的另一种新的模式：是并行的、点对点的、动态的多人协同开发模式，开发者之间通常仅仅靠互联网联系。
我们团队采用的是大教堂。
据我所知，应该是没有遇上过类似于迷失的情况。
Worse?Better?
我认为具体情况应该具体分析。对于一些精密度要求不高的软件遵循“worse is better”的设计理念还是可以的，但对于那些精度要求很高的软件，比如说航空领域的软件，我觉得显然不能为了追求simple而放弃其他的一致性和完整性。当然放在平时我们开发的软件，如果时间要求紧迫的话，我还是非常信奉“worse is better”的观点的，也许这就是导致我编译出现大泥球的原因。
瀑布
瀑布模型遵循"系统需求-->软件需求-->分析-->程序设计-->编码-->测试-->运行"这个流程，在设计大型系统时，需要做相邻步骤的回溯，解决上一阶段未能解决的问题。
其在软件工程实践中有一点给的局限性：①各步骤之间是分离的，但是软件工程生产过程中的各个步骤不能这样严格分离开来；②回溯修改很困难甚至不可能，但是软件生产的过程需要时时回溯；③最终产品知道最后才出现，但是软件的客户、甚至软件工程师本人都需要尽早知道产品的原型并试用。
敏捷
①尽早并持续的交付有价值的软件以满足顾客的需求；
②欢迎需求的变化，并利用这种变化来提高用户的竞争优势；
③可用的软件是衡量项目进展的主要指标；
④每日立会，讨论项目进展，今日工作进展以及明日工作安排；
方法论
软件工程的方法论在一定程度上可以帮助我们管理项目，但是我不认为在实际中强行硬套一个方法论会很有用，具体问题还是要具体分析，真正适合自己项目、团队的才是最好的。