程序员和建筑工人

不知哪时在哪里看到一个软件工程和建筑工程的对比...

前日吃饭的时候无聊，便提到这个:"你看,对面那栋漂亮的楼房。把他们建起来的是一群建筑工人,有些甚至被我们称为民工(这里,无歧视);而我们做软件的,大多受过高等教育,甚至很多被成为精英,为什么还把软件搞得这么糟糕。自从1968年软件危机第一次被提出以来,还长期存在。这是为什么呢?"

旁边的JJ说话了:"因为建筑师叫那些民工怎么做,他们就怎么做。而大多数软件开发人员都很有个性、很有想法,所以困难重重。"

偶抬杠:"这么说,去招一批民工来做软件,就可以解决这个问题?"

JJ无语,但还是很坚持。

旁边的猥琐男见状,正是提出自己高论的好时机:"这说明了建筑工程发展得很好了,而软件工程还没到达那个境界。这是一个长期、持续、抗争的过程,不过有一天会好起来的。"

嗯...科学的乐观主义者,他还在想着银弹。

偶想想,一位大师上课的时候说过:"软件本身是技术,但带着与生俱来的艺术性。"很多东西具有两面性,可以拿摄影来对比:一般人认为摄影是艺术,但它带有与生俱来的技术性。这大概不算矛盾,但却是统一体。

大师的回答着实很能回到这个问题:艺术能有完美的吗?所以软件也不能。你可以把软件的一面--技术做得很好,用很合理的技术,高超的算法;但是你永远不能把软件的另外一面--艺术做到极致。难道这就是传说中的哲学?

Oh,My God!!!我怎么会提起哲学?

软件是艺术。谢谢了，兄弟。知音哪。

其实很多行业做到高级水准，都可以上升到艺术。
比如，卖油翁，木工，武术等。
不过，艺术一般是说没有实用价值的。主要是带来精神的愉悦。
软件的创造性确实相对高一些。可以称为创造性工作。

软件做得差，我觉得，主要原因在于要求低，标准低。
当然，用于人命关天的领域中的软件，质量一定是很高的。
但是对于一般的软件来说。软件的标准比其他行业要低。
软件不是建筑。建筑盖得差，要死人的。而且，建筑难以修改。
软件可以反复升级修改。

这就使得人们对程序员的要求也放松了。加上程序本身就是带有创造性的工作，加上人的注意力问题，自制力问题，就容易出错了。
假设有这样的严格执法要求，软件出错，就要罚钱。那么质量就会高起来的。不过这样，也就提高了程序员的门槛，提高了程序员的工资，软件成本也就提高了。

楼上的,"软件出错，就要罚钱"不可定量,可执行性不高.

软件的艺术在于对业务的准确把握和信息归纳,优秀的软件相当于一个优秀的工程管理团队,用户只需要知道如何与它交流就能把握住问题本质.

如果是质量要求很高的软件，价格很高，进度不会很紧，测试会非常全面。
一般公司的做法，让测试人员找开发人员的bug。到年底根据bug的种类和数量评定绩效。
这种做法比较保守，属于不求无功，但求无过。

要最大发挥创造性，就要思考更好的机制。agile, xp, fdd, essensial rup 都是这方面的尝试。
有人发过帖子（tianxinet据此发挥过），即使测试的量化（覆盖率）也不能直接保证质量。

很多关键的东西确实难以量化。不能定量的，只能根据经验定性了。

没有公正的管理者,没有公平的机会,定性也是一句空话,我没有见到谁确实办好过,有时候觉得这是一句空话...
办公司政治在那里都存在的,有些人总能得到容易出效绩的工作,容易出问题的项目则总是给那些没有项目嗅觉的人,真是涝的涝死,旱的旱死.
指望别人都是空话,只能要求自己保持项目嗅觉,以免陷入项目陷阱.

这种类比没有什么意思。

你怎么知道一个外表看起来很漂亮的building，里面就不是充满各种各样问题的呢？现在豆腐渣工程，盖的很糟糕的小区比比皆是。买房子一不小心买到质量残次的楼盘，然后打官司的，你随便找到房产论坛去看看吧，多到令你吃惊的地步。

开发软件也是一样的，你让美工做个漂亮的首页，然后给客户demo一下，唬的客户眼花缭乱的，那还不是小意思的事情吗？他怎么可能知道你里面的代码全部都是垃圾？

楼房，你不搬到里面住个几年，就光在外面看着光鲜，贸贸然下定论，说这个building有多好多好，就和你给客户demo一下，那都是一个意思。所不同的地方在于，楼房要盖好了才能demo，但是软件只要美工做几个页面就可以demo了，所以楼房不会离谱的太狠而已。

把软件归结为艺术，与把一切归结为"道"一样，属于比较肤浅或者缺乏精度的解释。如同问:你在哪里?答曰：我在地球上。

而buaawhl提出的“质量要求”论就比“艺术论”来的更深刻与精确一些。虽然是否“准确”还有待考证。

buaawhl提到“测试会非常全面”---但软件中其实也存在所谓的“软件测试测不准原理”的说法。“全面测试在简单情况下是可能的，但非常有限”。由于"NP完全问题"的存在，必然导致“测试无法全面”.(我这里的推论过程可能有误，因为这个推论建立在对"NP完全问题"的理解上)

"NP完全问题"是另外一个有趣的话题了，不过我对NP完全问题也只是初步了解，不便多说，大家感兴趣可以google一下:)

我想过这个问题，而且有了结论
软件本质上是对变化编程，一个功能完全一样的软件不需要在第二个地方再编一遍，而是通过各种手段复用上去。
但是建筑就不同，完全一样的两个建筑也需要同样的成本和工艺实施两次，但是软件是可以复制的
因此大量讨论里面把建筑工程和软件工程进行类比是完全错误的

“记住，布利奇特，”女主人对新来的女仆说，“我将要求你两件事：老实，听话。”
“是，夫人。”布利奇特回答道，“如果您让我告诉客人您不在家，而事实上并不是这样，那我该怎么办？要老实说，还是要听话？”
--------------------------------------
上面的笑话，与“测试”有关，也是"NP完全问题的一个缩影"。
测试要求一：老实
测试要求二:听话
但在某种情况下，要求一和要求二是“矛盾”的----你怎么能保证“全面测试”，同时避免矛盾和不一致？
假如测试要求有100个，这一100个要求任意组合，你怎么能够保证“全面测试”，同时避免矛盾？
看上去和谐一致的要求和命题，其实包含了逻辑上的矛盾。而且这种矛盾并不是很显然的。----软件包含了逻辑，因此免不了遭遇类似这样的逻辑上的困境