Kelly Johnson提出了KISS原则。他是一个飞机工程师以及航空发明家，同时也是一个管理天才，他一生中主要设计了40多架飞机，获得的荣誉相当之多，总之，很牛。
这个原则是对Johnson带领的设计工程师团队最好的例证，他们在设计飞机时，必须考虑
到假如飞机在交战情况下出了故障，如何让普通的机械师修理飞机？
这就是这个原则产生的历史背景。
因此，stupid不是愚蠢的意思，而是指普通。
讲一个小故事：日本最大的化妆品公司收到客户抱怨买来的肥皂盒里面是空的,于是他们为了预防生产线再次发生这样的事情,工程师便很”努力辛苦”的发明了一台X-光监视器去透视每一台出货的肥皂盒。
而同样的问题发生在另一家小公司,他们的解决方法是买一台强力工业用电扇去吹每个肥皂盒,被吹走的便是没放肥皂的空盒。
做为IT行业，在平时遇到类似的事件会更多，如架构师做架构时，是以Stupid为原则？还是以需要180的智商才能理解为原则？开发同事写代码时，以其他开发同事很容易理解为原则？还是以程序可以运行就行，除了自己谁都别想看明白为底线？
几乎所有人都明白这个简单的道理，说出来没有人不懂，我们都知道KISS的好处，但为什么我们会做一些不KISS的设计？做一个不KISS的程序呢？
你想因为你的设计没有被很好的理解而半夜被人电话吗？你想因为你写的程序别人无法修改而被周末强制加班吗？当然不想，但为什么我们都这样做了呢？
因为我们没有真正了解我们的需求是什么，目标是什么。
为什么工程师会“努力辛苦”去发明一台X-光监视器，而不考虑使用电扇呢？可能被委派去发明监视器的工程师根本不知道自己发明的监视器是为了透视一个没有肥皂的肥皂盒。
另外一个原因是社会压力大、节骤快，导致时间碎片化，让我们更加需要KISS。想一下，你上次看微博是几小时甚至几分钟之前？而你上一次去看博客是几天甚至几周以前？
微博的到成功是因为运气好，是因为我们没有很长的时间去阅读一篇1000字的文章，大多数情况下我们也没有时间去阅读一个需要1小时才能理解的设计文档或类程序，而如果你这样做了，你的恶梦就开始了，或者已经开始了。
不要让人烦，不要让大家做功课。别指望他们愿意额外花些功夫去折腾你的东西。什么都不要指望，提供一个有用的东西就够了：把你的主要想法用一种方便理解、易于切入的形式呈现出来。如果你的想法很简单，但是描述却弄得十分繁琐、令人失望就不好了。挫折感是吞噬好想法的恶魔。
简单很好，但简单并不是少，比如写代码，3行代码能实现的逻辑如果用10行写肯定不好，不够简单，但如果写成了1行，同样会不够简单。因为这行代码包含了太多的内容，因为几个月以后你自己再看，都有想哭的感觉。这是什么意思！这是另外一种复杂，隐藏的复杂，比直观的复杂更害人。
我理解的KISS就是简单，不需要解释的简单，普通的简单。
SO，让我们开始KISS。
Keep It Simple Stupid!
