Writing Software is Like … Writing
http://www.artima.com/weblogs/viewpost.jsp?thread=255898
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.
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.
当然类比成为science/math或者是engineering来说都是不太合适的，和software development始终存在偏差。如果和math/science类比的话，那么软件应该是绝对正确的，而如果类比成为engineering的话，那么engineer应该是可以完全替换的并且有接近的生产力，但是事实上却不是。
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.
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.
使用认证以及一些标准化的手段来评估软件开发者能力的话是没有任何意义的
We're writers.
Most people can put words together into sentences. They can communicate adequately without being great writers. Most programmers can write some kind of program. It probably won't be very good, but most companies don't really need it to be very good. Most companies only need basic programming skills. A college degree in computer "science" from anywhere is good enough, and the job is just a job. It doesn't require much in the way of continuing education, conferences, workshops, or someone who is so interested in the craft of programming that they are always trying to learn more.
Such people can write, but it's just basic writing. They are not essayists or novelists – and keep in mind that there are lots of articles and novels that get published that are not particularly well-written or worth reading. Obviously such things seem to sell well enough to make the effort and risk worthwhile all around.
能够写和成为小说家或者是散文家之间还是存在很大区别的，这个编写程序一样，能够编写程序和写出好的程序也是存在很大差别的。有大量的文章是被写出来，但是实际上有大部分的文章并不好也不值得阅读，程序和文章一样，有大量的程序编写出来，但是只有少数程序非常良好。而大部分公司不需要程序非常良好，所以只需要开发者具备编程能力即可，也就不需要更多的锻炼和学习。
But someone who dedicates themselves to writing, who goes through the struggle of figuring it all out and discovering their own place in the world – this is a very different kind of writer (of prose or programs) than the average programmer. This person can produce more functionality faster, and the results will be clearer and deeper than ordinary code.
Finishing a novel is a very impressive feat. Doing something that might be worth publishing – that's an even greater feat. But the vast majority of published novels aren't worth reading. Only a small fraction of writers create something really worthwhile, and no one, really, knows how they do it. Each good novelist comes to their art in their own way. And what about nonfiction? Every year there are about 5000 novels published, and about 50,000 nonfiction books. Most of those nonfiction books are merely functional, not great reading. But they contain useful information and enough people buy them to make it all worthwhile (to the publisher, at least).
This answers one of the biggest questions – why you can't replace a programmer with just any other programmer and get similar results. It also suggests that you should evaluate what kind of project you're creating when you decide who your team should be, and how it will run. The creation of mysteries and young adult fiction and so-called "bodice rippers" and the vast sea of nonfiction books all have their own particular structure and constraints (you'd be surprised at how rigid and controlling publishers are about these things, as if they are manufacturing some kind of basic commodity – "the murder has to happen in the first 10 pages" etc.). None of these are the mass-market bestsellers ("killer apps") that are sold by the author's voice and style (few of which I find readable). The mass-market bestsellers usually don't coincide with the great writers, since most people don't have the patience to read these meta-craftsmen, just as most programmers don't read the source code for compilers.
编写程序和写作是一样，都需要长时间的练习，阅读，观察，和创作。这也解释了为什么不能够使用一个程序员替换另外一个程序员得到相似的结果，是因为每个人对于编写程序的深入程度以及知识面是不同的。