回到2004年，那时我还是一名初级开发者，工作在一个大型团队中，主要从事有线电视公司的账单与供应系统。就像所有的大型系统一样，这个系统由大量相对比较独立的组件构成，不同的小组负责不同的组件开发工作。模拟电视与数字电视供应系统几乎是完全分开的，由两个不同的小组分别进行开发。
模拟电视团队决定根据Microsoft Biztalk的一个早期版本来构建他们的系统。团队有4个人以及一个来自于微软的团队共同开发并运行这个系统。他们看起来工作非常努力，常常工作到深夜，周末也在加班加点。当遇到生产问题时，团队的每个人都会放下手头的工作，围拢在一起，提供各种建议和意见，以及如何修复问题的见解。你会看到，这个团队中的每个人都有很强的团队凝聚力，而且他们工作都非常努力。
数字电视供应系统则大相径庭。系统的代码几乎是由一个家伙搞定的，我们暂且称这个家伙为Dave吧。我是团队的一名初级维护工程师。一开始，我在理解代码时遇到了很多麻烦。程序中并没有长长的过程语句，相反有大量的小体积类和方法，每个方法的代码也只有寥寥数行而已。我有几个同事抱怨Dave将事情搞得过于复杂了。不过Dave却建议我应该阅读几本关于面向对象编程的图书。他教会了我设计模式、SOLID原则以及单元测试等知识。很快，他所编写的代码开始变得具有现实意义了，随着我不断加深对代码的理解，我也越来越发现它优雅的设计。代码在产品中没有出现问题，只是一直在默默地工作。要想对代码做出修改也是轻而易举的事情，因此实现新的特性简直是手到擒来。单元测试意味着进入到生产系统中的Bug数量变得微乎其微。
结果就是我们这个团队看起来工作不那么努力。我每天下午5:30下班，周末也从来不用工作，我们也不必围聚在一起猜测到底是什么原因导致了生产系统的问题。从外人的角度来看，我们所从事的工作肯定要比模拟电视团队的简单得多。事实上，二者的需求非常相像，只是我们开发出了设计更好的软件、提供了更好的支持基础设施，特别是单元测试。
更多见：http://blog.csdn.net/ricohzhanglong/article/details/17485219
写的好的代码，出现bug少， 容易维护，看起来外人觉得你很闲......