传智播客－Writing Software is Like ... Writing（译文）（1）

前言：
今天学的lucene，本来想写的，可是google了一下，今天能写的内容，网上都有，自己暂时也没什么很独到的心得，就算写出来也是Ctrl+C和Ctrl+V的感觉，于是挑了一篇很久以前看的Bruce Eckel的博文替代，读了这篇文章，多少会对“软件开发”有一个更清晰的认识。

传智播客lucene课程的视频暂时还没有在网上公开，有兴趣的同学可以google百度自己学习（推荐一下，网上有一篇不错的文章，csdn上也有一个研究生上传了关于学习lucene的资料及他写的源代码－－好像是他的毕设），或者来传智播客亲自聆听老师讲解：）

 

原文地址http://www.artima.com/weblogs/viewpost.jsp?thread=255898

（个人以为，这篇文章的思想和人月神话有的地方类似，不过表达的目的不一样）

 

Computing Thoughts
Writing Software is Like ... Writing
写软件就像。。。写作
by Bruce Eckel
April 21, 2009

 

Summary
摘要

I finally figured out the right analogy for software development. Alas, the target audience for this analogy won't be happy with it.
我最终领会到了软件开发的正确类比。唉，（但是）这个类比的目标读者将不会乐见于此。

 

---

 

Why do we need an analogy? We know what we do. We program computers, with all that entails. And we know what that means, because we do it.
为什么我们需要一个类比？我们知道我们在做什么。我们尽一切所需编写计算机程序。而且我们明白这样做的意义，因为我们就是做这个的。

 

But to the stakeholders -- managers, CEOs, customers, shareholders, etc. -- software development is a mystery. They don't want to know everything about it, but they want to know enough to be able to predict the behavior of software development, at least approximately.
但是对于（项目）利益相关人－－经理，CEO，客户，股东等等－－软件开发是神秘的。他们并不想了解有关开发的所有事情，但是他们希望有足够的了解以便预计软件开发的行为，至少大体上（了解）。

 

So stakeholders need an abstraction. An analogy. But for the analogy to be useful, it needs to hide the things that aren't important, and show the things that are. We've been flailing about with this problem for a long time, but we've always been putting it in our terms, and it all makes sense to us, so we can't differentiate between a useful analogy and one that is less than helpful.
因此（项目）利益相关人需要一个概念萃取。一种类比。但对于一个有用的类比，它必须隐藏那些不重要的东西，然后显示（被类比）事物的本质。长期以来在这个问题上我们一直是失败的，我们总是用我们的术语来解释这样的问题，这对我们有意义，因此我们不能区分有用的类比和没什么帮助的类比。

 

Mathematicians and engineers were the original programmers, so naturally we tried making it a science, and then engineering. Mostly we discovered that no matter how much we want software to be like mathematical proofs or bridge-building, it isn't.
数学家和工程师是最开始的开发人员，因此我们会自然地试着先视其为一种（自然）科学，然后是工程学。大部分时候我们发现无论我们（多么）希望软件像数学证明或桥梁建筑物一样，却总是事与愿违。

 

The stakeholders, trying to follow our analogies, asked questions that were important to them. "If programming is like math, why are programs always broken? Math is right or wrong, software is just broken." And later, after we gave up on the science analogy, "If programmers are like engineers, I should be able to replace one engineer with another and get similar results, right?"
（项目）利益相关人，尝试着理解我们的类比，询问一些对他们而言很重要的问题。“如果程序像数学一样，为什么程序总是有问题？数学不是对就是错，而软件仅仅是坏掉。”然后，当我们放弃科学类比之后，“如果开发人员像工程师一样，我应该能够用一个工程师取代另一个工程师而且仍能得到类似的结果，是吗？”

 

This latter has been a huge source of consternation among stakeholders. By and large, engineers have similar productivity levels. And the results produced are verifiable. There's a lot of consistency in engineering, and if we call it "software engineering," then there should be similar consistency in software.
而后者一直都是（项目）利益相关人巨大愕然的根源。基本上，工程师有着类似的生产水平。而且生产结果也可以证实。工程（学）有很多一致性，如果我们称开发为“软件工程（学）”，那么（各）软件（之间）就应该有着相似的一致性。

 

The two typical approaches to this problem have been either big denial ("ignore the differences and pretend all software development is the same") or little denial ("The differences are accidental. We can force consistency").
对于这个问题的两个典型的方法至今不是断然否认（“忽略掉不同之处然后假装所有的软件开发都是一样的”）就是略微否认（“区别是次要的。我们能够强制（使其）一致”）。

 

Big denial just doesn't work. But little denial has produced repeated attempts at "standardization of software engineers," the most notable of which is certification. If only we had a certification process, the argument goes, then software engineers would be like real engineers, and they'd all be consistent.
断然否认仅仅是无法（展开软件开发的）工作。但略微否认却总是（导致）产生重复尝试“软件工程师标准化”（的问题），最显著的就是认证。如果我们只有认证过程，就没有争论了，然后软件工程师就会像真正的工程师，全都具有一致性。

 

Fortunately certification has never gotten very far, because programmers could never be bothered to take such a thing seriously, and employers want to be able to hire the best programmers without regard to whether they have any particular degrees or credentials. And the certification programs that do exist are always done for money, and that seems to inevitably flatten the curve. I don't know anyone, for example, that takes the basic Sun Java Certification seriously. The more advanced Java certifications seem more interesting, but they also appear much more like workshops and less like tests to me.
值得庆幸的是认证（过程）从未走得太远，因为程序员从不会认真对待这样的事情（指认证）而（使自己）分心，而老板希望能够雇到最好的程序员而不会考虑他们是否有任何特别的学位或证书。认证程序（个人以为在这里可以理解为认证体系）的存在只是为了钱而已，而这好像无可避免地会走上这条路。举例来说，我就不知道有谁认真对待过基本的SUN Java认证。更高级的Java认证好像很有趣，但它们同样更像题学术讨论（会）或者对我而言有点像（能力）测验。

 

At one point I ridiculed this attempt to make all programmers identical cogs in a machine by reducing our activity to its simplest behavior in Programming as Typing.
就某方面而言我嘲笑这种通过简化我们的工作使编程变成像打字这样最简单的行为以将所有程序员都磨成机器中同样的齿轮一样的尝试。

 

So we're not scientists, and we're not engineers. How do we describe what we do to non-programmers in a way that makes sense to them? In particular, in a way that explains why there's such a big difference in programmers, in programming projects, and in the success and failure of projects?
因此我们不是科学家，也不是工程师。那么我们如何向非程序员描述我们的所作所为而且（这种描述）稍微又能令他们明白呢？尤其是，用一种（什么样的）方式解释为什么在规划项目，在成功和失败的项目之中，程序员之间有巨大的差别呢？

 

Here's my proposal. I think it explains everything. It will be very unsatisfying to stakeholders that want completely predictable behavior, and who want to replace one programmer with another and get identical results. (That's still not going to happen. The only compensation for the unpredictability is approaches like the Agile methods, which increases the bandwidth of communication with the stakeholders).
这里是我个人的建议。我认为它解释了一切。对希望完全预计（软件）行为的利益相关人，和那些希望（即使）用另一个程序员取代某个程序员也能取得同样结果的人而言这将不那么令人满意。（这种情况仍未发生。唯一可以对（软件行为的）不可预计作出补偿的就是像敏捷（开发）这样的方法，它拓宽了与利益相关人的交流）

 

We're writers.
我们是作家。