在《no silver bullet》中，作者提到两种软件开发的困难：
1.本质性：软件本身在概念（conceptual）建构上存先天的困难；亦即如何从抽象性问题，发展出具体概念上的解决方案。
2.附属性：将概念上的构思施行于电脑上，所遭遇到的困难。
而造成本质性困难的原因是：
1.复杂性（complexity）：软件要解决的问题，通常牵扯到计算步骤，这是一种人为、抽象化的智能活动，多半是复杂的。
2.隐匿性（invisibility）：尚未完成的软件是看不见的，即使利用图标说明，也常无法充分呈现其结构，使得人们在沟通上面临极大的困难。
3.配合性（conformity）：在大型软件环境中，各子系统的接口必须协同一致。由于时间和环境的演变，要维持这样的一致性通常十分困难。
4.易变性（changeability）：软件所应用的环境常是由人群、法规、硬件设备、应用领域等，各因素所汇集而成，而这些因素皆会快速变化。
在《big ball of mud》中，大泥球是指一个随意化的结构化系统，纯粹代码的堆积，会导致很多的错误和缺陷。
产生这种缺陷的原因是：
程序员在编写程序的时候遇到问题后的解决方案往往是改动最小的，而不是最合适的。导致程序的结构发生问题，为日后程序崩溃埋下了隐患。其次，由于用户需求的不断改变，程序员在不断修改程序的时候会将原有程序变得更为复杂，使程序变成一个大泥球。因此，为了避免程序最后变成一堆混杂的代码，应该在编码前期尽可能的搭好整个框架，在修改代码时也尽可能的考虑整体架构。
在《Cathedral and the Bazaar》中，有两种模式的开发方式：
大教堂模式（The Cathedral model）︰原始码在本模式是公开的，但在软件的每个版本开发过程是由一个专属的团队所控管的。作者以GNU Emacs及GCC这两软件为例。
市集模式（The Bazaar model）︰原始码在本模式也是公开的，不过却是放在因特网上供人检视及开发。作者以Linux核心的创始者林纳斯·托瓦兹带领Linux核心的开发为例，亦引用fetchmail的开发为例。
在我参与的结对项目中，一个人编码，一个人检查这种方式类似市集模式。但是在团队项目中，我们的开发人员本来就不多，没有办法专门找人来做检查。只能大家在移植代码的过程中不断修正错误。
在《worse is better》一文中提到：
普遍认为是好的方面：
1.简单性：从前认为在实现和接口中，设计必须简单。简单性是设计中最重要的。
2.正确性：在所有可观察的方面，设计都必须正确。正确的重要性亚于简单性。
3.一致性：设计必须一致。但是退一步讲设计只要不是过于不一致就好了。
4.完整性：设计要覆盖很多种情况，但一旦阻碍了其他方面一定会先牺牲完整性。
而我在自己做项目的时候基本上也是根据这些原则做的，可能有时不会把所有原则的重要性排列的如此细致。
读完这些文章我认为软件工程是大学生到公司程序员的一个过渡，很多东西都是在一个团队做工程的时候才会遇到的问题。我从这门课中学到的不仅是在编写代码时应该注意的东西，还有在团队项目中，大家合作时应该注意的东西。虽然很多程序员的能力完全可以在一段时间内自己做完一个工程，但是很多人一起合作的时候，这种效率与正确性是一个人完成不了的。