工廠的重組 是時候給軟體工程師提供更多的工具了

2021-10-19 17:58:51 字數 3957 閱讀 4817

在開發人員中流行的態度是,抱怨我們的工具和東西有多爛。或許我是個樂觀主義者,因為我的觀點完全相反!1999 年,我得到了第乙個軟體工程師的工作,在過去的二十年裡,我見證了軟體工程的變化,使我們的工作效率提高了好幾個數量級。僅舉一些我曾經做過或者接近做過的事情的例子:

更不用說開發過程中的變化了:

這些只是例子——我可以說上一整天。正如關於軟體生產力的經典**《 沒有銀彈 》( no silver bullet ),這些東西本身並沒有什麼顯著的進步。但生產率的增長是累加的,並且是以對數尺度累加起來的,也就是說,當你的時間尺度是幾十年的時候,我們看到的將是數量級的增長,這不是沒有道理的。

對於世界有一種極為粗略的分類:

到目前為止,這一點已經很明顯了,因此我繼續說下去:如果有一種能力,能夠在零成本的條件下,瞬間生產出無限量的軟體,那麼最後兩種分類將不再存在。平庸的軟體之所以存在,是因為有些人沒有能力僱傭更好的工程師,或者他們沒有時間,或者其他什麼原因。沒有軟體的東西……算是萬能的嗎?我是說,為什麼你的鞋子裡沒有內建計步器?為什麼會計裡的標記還能生成 pdf 發票,並通過電子郵件傳送給客戶?怎麼不……我還能說更多。

很明顯,我們一直在向這個方向努力,而我的觀點是,仍然有很多東西可以使用軟體。那為什麼還沒有發生呢?由於一些人做出經濟決策,他們 認為構建這些軟體的成本太高 。僱傭工程師、培訓工程師以及把事情做好,都需要金錢和時間。那麼,我們如何看待這種成本呢?

現在回到我的觀點,即軟體工程師的生產率會隨著時間而提高。用經濟學術語來說,這意味著單位時間內的產出價值將增加。就需求而言,這意味著構建軟體的成本降低了。過去需要 1000 個小時才能完成的事情,現在需要 100 個小時就能完成。

如果需求是固定的,那就意味著大規模失業和工程師工資的降低,但需求並不是固定的!正如我前面所暗示的那樣,構建軟體的成本降低意味著新的機會的出現。以前,構建你的小工具不值得花費 1000 個小時的工程努力,但花費 100 個小時還是值得的。這裡面存在著巨大的潛在需求。你甚至可以支付工程師更多的時薪。

這些情況可以同時發生:

這可能有悖於直覺,因此值得拿它和固定需求進行比較。假設發明了某種工藝,使紙尿褲工廠的產量提高了 10%(保持所有成本不變),並且這項發明可以立即提供給所有紙尿褲製造商。結果會是什麼呢?紙尿褲市場將出現暫時性的供過於求,市場將趨於乙個新的平衡點,即**量萎縮以滿足需求。在這個過程中,一些工廠將會關閉,紙尿褲的**也將會下降。

這種情況會一直持續下去嗎?我想在某種終極狀態下,我們會遇到類似奇點的東西,軟體本身製造軟體的速度如此之快,以至於需求不能隨著**而增長。在這個時候,我會為軟體工程師的失業擔憂。但是我想,在未來的幾十年中,我們會看到越來越多的軟體工程師出現在我們的視野中。

很明顯,軟體作為乙個領域的發展和薪資的增長,本身就吸引了更多的人進入,但是我認為還有一件事在發生。

幾十年前,軟體工程非常困難,因為你必須從頭開始構建一切,並解決所有這些基礎問題。你需要儲存空間來為 100 萬併發使用者提供服務?閱讀關於一致雜湊演算法,cap 定理,crdts 之類的**,捲起袖子,準備好迎接 10 萬行硬核 c++。

如今,這些問題大部分都已經解決了,你可以使用現成的工具來解決這些問題。但那並不容易!正如我之前提到的,這裡沒有銀彈,只有數以百萬計的工具,你需要知道如何根據最佳實踐來組合這些工具。但是我們知道這是另一種困難。

數十年前的軟體工程傾向於那些能夠把複雜軟體從原子中拼接出來的深奧抽象思維者。在我看來,今天的軟體工程更像是一門手藝:更多的是了解應該使用哪些工具來完成哪些工作。我是說,它仍然非常偏愛那些更深層次的抽象思維者,但是相對來說,這種技巧的差異比過去更小。

我認為這改變了供給側的方程式。現在,阻礙軟體工程師成長的因素已經變得不同,這為他們開啟了更大的人才庫。這樣就有了新的**,這意味著更多的軟體將會誕生。

對於公司來說,構建軟體過去是,現在仍然是一項非常昂貴的工作。在一般的公司裡,你的積壓工作仍然無休止地存在。工廠的軟​件方面通常仍然是公司的瓶頸。

當你有乙個部件製造商是製造工廠的瓶頸時,你該怎麼辦?你要確保瓶頸在任何時候都能得到充分利用。這意味著你可以集中小部件製造商的資源管理:你可以控制輸入,並且盡力確保按照什麼順序生產哪些部件。

大多數公司的運作方式仍然大致如此。但是,那些(在我看來)擁有高效率工程團隊的公司,他們的組織方式略有不同。他們傾向於分散優先順序,並直接與產品和業務利益相關者一起進行緊密的迭代。如果某個資源不再是瓶頸,你就可以通過在許多不同的團隊中分配資源,從而顯著提高迭代的速度。我的意思並不是說管理要分散開來,要說清楚。我是說要把積壓的工作分散到小團隊中,直接根據業務需求來做。

你沒有乙個營銷團隊在這個模型中把一些東西放進了工程團隊的積壓中。你有乙個跨職能的團隊,他們擁有自己的收購權,其中一些人是傳統的營銷人員,一些人是工程師。你可以想象得出一家典型公司的幾乎所有功能:客戶支援、財務或任何其他。

在歷史上,有個很有意思的模擬,那就是 為什麼電力用了那麼久才改變了製造業 。在蒸汽機時代,工廠是圍繞著萬能的蒸汽機的動力分配而建造的。能源是寶貴的資源,因此很自然地認為製造工廠就是圍繞著能源分配而建立的。電力改變了這一點,也改變了分散的能源生產方式,但是製造工廠要重新調整和利用這種方式,真的需要很長的時間。

(注 1:這個模擬並不十分恰當,因為蒸汽動力不僅是一種寶貴的資源,而且難以製造出小型蒸汽機。)

對於提高工程師工作效率的工具,我已經談了很多,但是還不夠全面。顯然,還有很多非技術人員使用這些工具來做他們自己的事情,這是好事!但是,我也看到很多任務具是為了讓人們不必和工程師合作。為什麼這樣說?原因是多方面的。

迭代速度:向工程師解釋所需成本,使得它不值得去做。

工程資源不到位(或過於昂貴,或者其他)。

需要的只是工程師的一小部分,但是市場並不存在。

構建一些東西需要一些特殊的領域知識。

工程師們很怪異,而且身上有怪味。

好吧,最後乙個理由只不過是乙個愚蠢的玩笑。但我認為其他的觀點已經涵蓋了大部分。

在這些理由中,我認為第乙個原因(迭代速度)是 100% 合理的。舉個例子,我鼓勵所有的業務人員學習 sql,這樣他們就可以自己執行查詢。

我覺得不幸的是第二個原因(工程資源不到位)。很多人都會遇到這樣的情況:人們手動傳送帶有巨集的 excel 檔案,每天早上將新資料複製貼上到電子**中,或者其他類似的事情。這有時被稱為 「 影子 it 」。在擁有專業工程資源的情況下,構建和擁有這些東西的總成本可以大大降低。

但事實是,沒有工程師在製造技術,這證實了對工程師的需求。許多公司的工程師是無法滿足需求的。因此,隨著時間的推移,通過更好的工具能夠滿足更多需求。站在工程師生產力前沿的公司,很可能不太注意到這些問題:工程師會盡早介入並致力於解決商業問題。

第三個原因(部分資源)對小公司來說也許是對的。假如你是一名牙醫,你不會僱一名工程師為你建立乙個預約系統。幸好,他們得益於全行業產出的增加:乙個全新的牙醫軟體生態系統可供購買(因為構建它要便宜得多)。

最後乙個原因(特殊知識)有些道理。我們常常看到業務人員建立人工工作流程,然後由工程師來完成,並將其自動化,作為一種一線的技術攻關,以實現基本的原型。相應地,隨著去中心化程度的加深,工程師們將會越來越多地積累專業知識。比如,許多公司為人力資源和財務團隊提供了專門的資料科學和資料工程資源。

其中乙個有趣的推論就是,它形成了乙個積極的反饋,一些公司甚至會更落後於人:

在合同中,處於這一前沿的公司將會看到他們的軟體工程師的生產力激增,迭代速度提高。

我在抵押貸款行業呆了六年,我已經非常清楚地看到這些趨勢正在我的眼前上演。最大的落伍者都在竭盡所能地 機器**程自動化 和「管道膠帶」,以及現成的 pos 和 crm 軟體。稍微好一點的公司都有自己的工程團隊,但是似乎沒能將流程工廠重新調整成乙個技術驅動的公司。我的公司 better 隱含著對我在這篇文章中提到的一切的賭注,或許還有其他一些趨勢。

我認為這些詞彙可以簡潔地用於因果關係圖:

很明顯,這個理論並不完全適用於軟體。其他趨勢如網際網路抹掉了物理護城河,軟體創造了更大的規模經濟效益。但是我認為,這能解釋許多問題。

如果一種理論不能做出**或政策建議,那麼它就不會有任何作用,因此我敢打賭:

這篇文章融合了我頭腦中以前無關的觀點。有一些也許對讀者非常明顯,有一些則不然。但願你能在後者中找到一些有用的東西!

是否是軟體工程師。

十月的乙個寒冷的夜晚,我坐在不舒服的椅子上,morgan著摩根船長和葡萄柚蘇打水。我是一家大型汽車公司的專業軟體工程師。我為他們的電動汽車編寫軟體。我剛發現這個 而我做的第一件事就是訂閱初學者執行緒。嘆。我之所以沒有這樣做,是因為我想重新整理基礎知識或幫助新的開發人員。我這樣做是因為我感覺自己沒有任...

給軟體工程師們的建議

1 好好規劃自己的路,不要跟著感覺走 根據個人的理想來安排自己的生活,絕大部分人並不指望成為什麼院士或教授,而是希望活得滋潤一些,痛快一些,那麼就需要慎重安排自己的軌跡,從乙個行業入手逐漸對該行業深入了解,不要頻繁跳槽,特別是不要為了一點工資而轉移陣地,從長遠看,這點錢根本不算什麼,當初你對乙個行業...

給軟體工程師的自學建議

給軟體工程師的自學建議 與現在大學生的情況類似,學校學的專業知識總是與實際工作中需要的知識相差甚遠。或許進入我們這個行業就注定要一輩子不離書本 不離學習了。由於軟硬體技術的推陳出新,學校教的c basic pascal foxbase還真從來沒直接用於實際工作中過,後來工作中用到的具體知識全憑畢業之...