開發抽象層

From The Joel on Software Translation Project

Revision as of 13:56, 19 October 2006 by Mph (Talk | contribs)
Jump to: navigation, search
  • 2006 年4 月 11 日

城裡來了個年輕人。他外表迷人,口袋裡也有些錢,女人們都樂意與他交談。

對於自己的過去他並不多談,但誰都看得出來他在大公司蹉跎了多年的青春。

年輕人的個性和善又外向,充滿了信心卻又不流於傲慢。也因此,他很快就開始在當地程式員聚會中接了些小專案來做。然而對於這些保單資料庫、銷售女性配件的網頁、財務計算程式之類的小專案,他很快就興趣缺缺了。

在無聊工作一年以後,他終於存到了一筆一年份的生活費。與愛犬小亞商量後,他就在自己雜貨店樓上灑滿陽光的租賃公寓裡架了一台電腦,並安裝了一些精心挑選的程式開發工具。

他一一打電話告訴他的朋友們,如果他接下來的幾個月失聯的話,便是正埋首於工作中,請大家不要擔心。

一切就緒後,他坐下來開始打造他心目中完美的程式。

他最後創造出來的程式是多麼地迷人啊。完美無瑕、充滿藝術氣息、優雅,而且一個臭蟲都沒有。由於使用者介面也完全符合人們的思考模式,他在當地程式員聚會中為同儕展示時,甚至沒有人注意到有使用者介面的存在。這是一個相當出色的傑作。

受到同儕所激勵,他開始設立公司並接受訂單。

雖然他並不懷著不切實際的期望,但一個月後他的銀行帳戶依然空虛。到目前為止他只接了三份訂單:一份來自母親、一份來自當地程式員聚會的匿名贊助,還有一份是他自己測試用的訂單。

第二個月過後,也沒有新增的訂單。

這個結果令他又驚訝又沮喪。他之前工作的大公司每次發表的新產品都沒什麼特別的。但即使產品不優雅也不漂亮,銷售量依然大好。他參與的其中一個甚至還相當熱賣。

又過了幾個月,他的經濟狀況開始顯得困窘。他的愛犬用哀傷的眼神望著主人,雖然不曉得到底發生了什麼事,但也知道主人的臉愈來愈憔悴了。年輕人甚至連約朋友出去,或是出門補充生活必需品及洗澡都顯得興趣缺缺。

在某個星期二早上,樓下的雜貨店開始不讓他繼續賒帳,城裡的銀行也很久不接他電話了。

他的老東家對他的離職並不懷恨在心。相反地,他們認同他的才華,也以更高薪找他回去工作。很快地,年輕人恢復了往日的光彩。他買了些新衣服,也找回失去已久的自信心。但他內心深處某些東西卻已不復見,那就是從前眼神裡的光芒。他原本期望能主宰自己命運的希望已幻滅了。

SCal2.PNG

他為什麼失敗了呢?他相信他早就知道了答案,「就是『行銷』!」他說。就像很多的年輕技術人員一樣,他總是這樣說︰「微軟的產品很糟,但是他們很會行銷。」

在軟體開發者的口中,「行銷」這個詞就代表了所有做生意的事︰創造軟體並且把軟體賣出去,正是軟體開發者所不懂的那些事。

其實,「行銷」這個詞彙的意思真的不是這回事。其實,微軟的行銷真的很糟。你能夠想像,那些用恐龍人偶當主角的廣告,真能讓人想掏錢買微軟的Office嗎?

軟體是一種對話 -- 軟體開發者與使用者之間的對話。但是,想讓這種對話發生,還需要很多軟體開發以外的事。沒錯,它需要行銷,但還需要銷售、公關,還有間辦公室、網路、基礎設備、辦公室的冷氣,還有客戶服務、會計,還有一大堆其他的支援性工作。

但是軟體開發者在幹什麼呢?他們在設計程式寫程式、他們編排畫面、他們除錯、他們整合、他們還會把程式碼給簽入到原始碼的控制系統中。

程式員的工作層次(比方說,Emacs)實在太過於抽象了,抽象到做不了生意。在抽象層工作的軟體開發者,還需要一個實作層 -- 一個能將程式碼轉換成產品的組織。桃莉巴頓(Dolly Parton)是在”唱好歌”那一個層次的,她也需要一個龐大的實作層,來幫她灌唱片、訂演唱會場地、賣票、音效、宣傳、收版稅。

SCal3.PNG

任何成功的軟體公司都會包括薄薄一層的開發者,這些開發者散佈在巨大管理組織抽象層之上建立軟體。

Any successful software company is going to consist of a thin layer of developers, creating software, spread across the top of a big abstract administrative organization.

這個抽象層存在的目的,只是為了建立一種假象,讓大家覺得一個程式員的日常活動(程式碼的設計及撰寫,程式碼的簽入、除錯等等),就是建立軟體產品並將之引入市場的一切。這一點讓我得出本文最關鍵的重點:

The abstraction exists solely to create the illusion that the daily activities of a programmer (design and writing code, checking in code, debugging, etc.) are all that it takes to create software products and bring them to market. Which gets me to the most important point of this essay:

身為軟體團隊經理,你的第一要務是建立開發抽象層。

Your first priority as the manager of a software team is building the development abstraction layer.

大多數軟體經理新人都未察覺這個重點。他們只會一直想由好萊塢電影學到的傳統命令式管理模式。

Most new software managers miss this point. They keep thinking of the traditional, Command-and-Conquer model of management that they learned from Hollywood movies.

在命令式的作法中,經理/團隊領隊會找出公司的目標,然後對副官下達適當命令把公司往讓方向移動。副官接下來會細分工作再命令下屬執行。這個過程會沿著組織圖往下重複進行,直到最後某個在最底層的人實際做事為止。在這種模式之下,程式員就是機器中的一根齒輪牙:一個執行管理階層命令中某一部份的打字員。

According to Command-and-Conquer, managers-slash-leaders figure out where the business is going to go, and then issue the appropriate orders to their lieutenants to move the business in that direction. Their lieutenants in turn divide up the tasks into smaller chunks and command their reports to implement them. This continues down the org-chart until eventually someone at the bottom actually does some work. In this model, a programmer is a cog in the machine: a typist who carries out one part of management's orders.

某些企業實際上就是用這種方式運作。當你遇到這種公司一定都能分辨,因為和你說話的人都會做某些沒大腦且惹人生氣的事情,他們自己知道問題可能甚至還會介意,不過卻無法可施。就是這種航空公司,會在客戶想更改不可退費機票趕回家處理急事時拒絕,結果失去一個時常坐飛機的重量級顧客。就是這種網際網路供應商斷線時間超過正常營運的時間,而且在你停用後還一直跟你收錢收錢收錢;而當你打電話去抱怨時,卻得打付費電話花一個小時等候轉接,結果還是拒絕退費,直接你開始寫網誌罵他們有多爛才作罷。就是這種底特律的汽車公司,長久以來早已忘記要如何設計出大家想買的車子,只會一直改變行銷策略,好像我們不買他們的爛車只是因為折扣打得不夠。

Some businesses actually run this way. You can always tell when you are dealing with such a business, because the person you are talking to is doing something infuriating and senseless, and they know it, and they might even care, but there's nothing they can do about it. It's the airline that loses a million mile customer forever because they refuse to change his non-refundable ticket so he can fly home for a family emergency. It's the ISP whose service is down more often than it's up, and when you cancel your account, they keep billing you, and billing you, and billing you, but when you call to complain, you have to call a toll number and wait on hold for an hour, and then they still refuse to refund you, until you start a blog about how badly they suck. It's the Detroit automaker that long since forgot how to design cars that people might want to buy and instead lurches from marketing strategy to marketing strategy, as if the only reason we don't buy their crappy cars is because the rebate wasn't big enough.

SCal1.PNG

夠了。

Enough.

把它忘了吧。命令式的階層管理系統已經被試過了,在1920年代與推著車的小販競爭時,這種作法有一陣子似乎行得通,不過對21世紀來說並不夠好。軟體公司需要使用不同的模式。

Forget it. The command-hierarchy system of management has been tried, and it seemed to work for a while in the 1920s, competing against peddlers pushing carts, but it's not good enough for the 21st century. For software companies, you need to use a different model.

對一家軟體公司而言,管理的第一要務就是替程式員建立那樣的抽象層。

With a software company, the first priority of management needs to be creating that abstraction for the programmers.

如果某個程式員正為椅子壞掉而操心,或是因為等Dell送新電腦來閒置,表示這個抽象層已經有了裂縫。

If a programmer somewhere is worrying about a broken chair, or waiting on hold with Dell to order a new computer, the abstraction has sprung a leak.

把你的開發抽象層想像成一艘具備超級馬力的美麗大遊艇。遊艇的維護無懈可擊。美食準時送上。包廂每天有兩次整理服務。導航地圖隨時更新。全球定位系統和雷達從不出問題,就算壞了艙內也有備份。而在艦橋上則是只需要考慮速度方向以及午餐吃鮪魚還是鮭魚的程式員。同時有一大隊身著漿硬白制服的專業人員在甲板下悄悄活動,維持所有事情的運作、填滿油槽、刮除藤壼、熨平午餐餐巾。這個支援團隊知道要做什麼,不過全都聽從臭屁老領隊(salty old fart)的指示。後者只要往某個方向輕輕點頭,整隊人就會完全協調演出,讓程式員能把遊艇的細節全部抽象掉,只要管速度和方向,以後午餐要吃些什麼。

Think of your development abstraction layer as a big, beautiful yacht with insanely powerful motors. It's impeccably maintained. Gourmet meals are served like clockwork. The staterooms have twice-daily maid service. The navigation maps are always up to date. The GPS and the radar always work and if they break there's a spare below deck. Standing on the bridge, you have programmers who really only think about speed, direction, and whether to have Tuna or Salmon for lunch. Meanwhile a large team of professionals in starched white uniforms tiptoes around quietly below deck, keeping everything running, filling the gas tanks, scraping off barnacles, ironing the napkins for lunch. The support staff knows what to do but they take their cues from a salty old fart who nods ever so slightly in certain directions to coordinate the whole symphony so that the programmers can abstract away everything about the yacht except speed, direction, and what they want for lunch.

最需要為建立程式員的抽象層負責的就是軟體公司的管理階層。我們建造遊艇,我們服務遊艇,我們就是遊艇本身,不過我們不駕駛遊艇。我們做的每件事都是要為程式員提供一個無縫隙的抽象層,讓他們能創造出偉大的程式,再讓那些程式抵達能因而獲益的客戶手中。

Management, in a software company, is primarily responsible for creating abstractions for programmers. We build the yacht, we service the yacht, we are the yacht, but we don't steer the yacht. Everything we do comes down to providing a non-leaky abstraction for the programmers so that they can create great code and that code can get into the hands of customers who benefit from it.

程式員需要Subversion儲存庫。建立一個Subversion儲存庫意味著你需要一個網路和一台伺服器,必須去採購、安裝、備份,還要配置不斷電系統;伺服器會產生很多熱,表示你得準備一個有額外空調的房間去放;而空調得連接到大樓外,表示大樓外牆外面要裝一個80磅的風扇;安裝這東西會讓屋主緊張,所以他們得帶自己的工程師來,協調要在哪裡安置空調設備(決策結果:要裝在往上到18樓的外牆上,可能是最不方便的位置),而屋主也會拉律師進來,因為我們得付出許多才獲淮進行;然後當空調安裝人員出現了,還帶著有如芭比玩具組的吊索機具,讓我們的建築工頭緊張起來,不肯讓他們穿著半吋粉紅塑膠製的美泰兒(Mattel,譯註:著名玩具商)繫具爬出18樓窗外,於是有人得再把包商找來,搞清楚他們為什麼在施工12週後,會突然發現得為這該死空調再次修改合約,而且這東西早在耶誕節前就知道要裝但是剛剛才弄清楚。而這件事即使只讓你的程式員花一分鐘去想都嫌太多。

Programmers need a Subversion repository. Getting a Subversion repository means you need a network, and a server, which has to be bought, installed, backed up, and provisioned with uninterruptible power, and that server generates a lot of heat, which means it need to be in a room with an extra air conditioner, and that air conditioner needs access to the outside of the building, which means installing an 80 pound fan unit on the wall outside the building, which makes the building owners nervous, so they need to bring their engineer around, to negotiate where the air conditioner unit will go (decision: on the outside wall, up here on the 18th floor, at the most inconvenient place possible), and the building gets their lawyers involved, because we're going to have to sign away our firstborn to be allowed to do this, and then the air conditioning installer guys show up with rigging gear that wouldn't be out of place in a Barbie play-set, which makes our construction foreman nervous, and he doesn't allow them to climb out of the 18th floor window in a Mattel harness made out of 1/2" pink plastic, I swear to God it could be Disco Barbie's belt, and somebody has to call the building agent again and see why the hell they suddenly realized, 12 weeks into a construction project, that another contract amendment is going to be needed for this goddamned air conditioner that they knew about before Christmas and they only just figured it out, and if your programmers even spend one minute thinking about this that's one minute too many.

就你的團隊中的軟體開發者而言,這一切都必須被抽象化成只要在命令列鍵入svn commit。

To the software developers on your team, this all needs to be abstracted away as typing svn commit on the command line.

這就是要有管理階層的原因。

That's why you have management.

管理階層就是為了那些沒有公司能避免的事,不過如果讓你的程式員為此而操心,那麼管理階層就算失敗了。這就像如果百萬富翁船主得下去引擎室建造引擎,這台一百英呎長的遊艇也算失敗了。

It's for the kind of stuff that no company can avoid, but if you have your programmers worrying about it, well, management has failed, the same way as a 100 foot yacht has failed if the millionaire owner has to go down into the engine room and, um, build the engine.

有些典型的軟體公司是由前軟體業務開始,在這種公司裡銷量就是一切,所有人都是為了增加銷售量而存在的。市場上的這種公司可以辨別得出來,由於他們會製作軟體的1.0版(不知怎麼出來的),然後就完全沒興趣開發新軟體了。他們的開發團隊不是已經被餓死就是根本不存在,由於沒有人想到要去製造2.0版...管理階層懂的事就只有增加銷量。

You've got your typical company started by ex-software salesmen, where everything is Sales Sales Sales and we all exist to drive more sales. These companies can be identified in the wild because they build version 1.0 of the software (somehow) and then completely lose interest in developing new software. Their development team is starved or nonexistent because it never occurred to anyone to build version 2.0... all that management knows how to do is drive more sales.

在另一個極端是由前程式員所建立的典型軟體公司。這些公司比較難以發現,由於在大部份情況下他們都會安靜地堅持,在某個無人能發現的閣樓上磨亮他們的程式碼,於是他們就在「大Ruby重寫風潮」(Great Ruby Rewrite)後靜靜地被人遺忘,而他們足以改變世界,能重整程式碼的程式結果也無法被世人欣賞。(譯註:作者指Ruby太流行,一堆人用Ruby重寫程式而不重整程式,所以能重整程式碼的重要工具就被人忽略了)

On the other extreme you have typical software companies built by ex-programmers. These companies are harder to find because in most circumstances they keep quietly to themselves, polishing code in a garret somewhere, which nobody ever finds, and so they fade quietly into oblivion right after the Great Ruby Rewrite, their earth-changing refactoring-code code somehow unappreciated by The People.

當一家公司是由程式員驅動,在組織上讓程式員坐上駕駛座,同時卻有優異的抽象層能在甲板下完成所有把程式碼轉成產品的苦工。前面這兩種公司都會輕易地被這樣的公司消滅。

Both of these companies can easily be wiped out by a company that's driven by programmers and organized to put programmers in the driver's seat, but which have an excellent abstraction that does all the hard work to convert code into products below the decks.

要讓一位程式員發揮最大的生產力,必須搭配一間安靜的個人辦公室、一台強大的電腦、無限制的飲料,華氏68到72度的室溫、螢幕上沒有反光、一張極舒適而不會感覺到的椅子、一位替他們帶來信件和訂購的書籍手冊的管理者,一位讓網際網路讓氧氣般隨時可用的系統管理者、一位能找出他們自己看不到的臭蟲的測試人員、一位讓他們的畫面美麗悅目的繪圖設計師、一組讓大眾想要他們產品的行銷團隊、一組確保大眾能拿到這些產品的業務團體、幾位協助客戶使用產品,並讓程式員瞭解導致客服電話的問題,極具耐心的技術支援聖人、以及其他十幾位支援及行政人員,而這些在一家典型的公司裡總共會佔用八成的薪資支出。羅馬軍隊中每位士兵配置四名僕人的比例並非巧合。這並不是墮落。現代軍隊的比例可能高達7:1。(今天Pradeep Singh教了我一些事:如果在你的人員中程式員只佔兩成,而把程式工作外包到印度可以節省五成的薪水,那麼省下的一成支出究竟可以帶來多少的競爭優勢呢?)

A programmer is most productive with a quiet private office, a great computer, unlimited beverages, an ambient temperature between 68 and 72 degrees (F), no glare on the screen, a chair that's so comfortable you don't feel it, an administrator that brings them their mail and orders manuals and books, a system administrator who makes the Internet as available as oxygen, a tester to find the bugs they just can't see, a graphic designer to make their screens beautiful, a team of marketing people to make the masses want their products, a team of sales people to make sure the masses can get these products, some patient tech support saints who help customers get the product working and help the programmers understand what problems are generating the tech support calls, and about a dozen other support and administrative functions which, in a typical company, add up to about 80% of the payroll. It is not a coincidence that the Roman army had a ratio of four servants for every soldier. This was not decadence. Modern armies probably run 7:1. (Here's something Pradeep Singh taught me today: if only 20% of your staff is programmers, and you can save 50% on salary by outsourcing programmers to India, well, how much of a competitive advantage are you really going to get out of that 10% savings?)

管理階層的首要任務,就是創造出軟體公司能靠撰寫程式碼運轉的假象,由於這就是程式員所做的事。雖然擁有同時擅長銷售、繪圖設計、系統管理以及烹飪的程式員是很棒沒錯,但是並不切實際。就像教一隻豬唱歌一樣,既浪費你的時間又會惹惱豬。

Management's primary responsibility to create the illusion that a software company can be run by writing code, because that's what programmers do. And while it would be great to have programmers who are also great at sales, graphic design, system administration, and cooking, it's unrealistic. Like teaching a pig to sing, it wastes your time and it annoys the pig.

微軟在建立這種抽象層上做得非常好,以致於微軟離職員工開創公司時非常辛苦。他們就是無法相信有多少事在甲板下進行,也不知道要如何去重現。

Microsoft does such a good job at creating this abstraction that Microsoft alumni have a notoriously hard time starting companies. They simply can't believe how much went on below decks and they have no idea how to reproduce it.

SCal4.PNG

沒有人期望桃莉巴頓知道如何接上麥克風。她背後有一個無法想像,由經理人、音樂家、錄音技師、唱片公司、巡迴演出經紀人、美髮師、宣傳人員組成的基礎結構,這全部的一切只是要在她唱歌時建立那種抽象性,好像數百萬人會聆聽只是因為是她在唱歌。這所有讓桃莉巴頓得以實現的支援人員和管理階層所能做的最佳工作,就是提供最完美的抽象:那種桃莉巴頓為我們而唱的完美假象。這就是她的歌。當你用你的iPod聆聽她的歌,其實是有個巨大的基礎結構讓這件事實現,不過這個基礎結構所能完成最棒的事就是完全消失。只剩下桃莉巴頓獨自對我們唱歌這個完美的抽象意念。

Nobody expects Dolly Parton to know how to plug in a microphone. There's an incredible infrastructure of managers, musicians, recording technicians, record companies, roadies, hairdressers, and publicists behind her who exist to create the abstraction that when she sings, that's all it takes for millions of people to hear her song. All the support staff and management that make Dolly Parton possible can do their jobs best by providing the most perfect abstraction: the most perfect illusion that Dolly sings for us. It is her song. When you're listening to her on your iPod, there's a huge infrastructure that makes that possible, but the very best thing that infrastructure can do is disappear completely. Provide a leakproof abstraction that Dolly Parton is singing, privately, to us.


這些網頁的內容為表達個人意見。
All contents Copyright © 1999-2006 by Joel Spolsky. All Rights Reserved.

Personal tools