軟體開發是工藝還是工程？

一般人以「軟體工程」來說明軟體專案的開發過程，但對於軟體所要解決的問題不複雜、參與開發的團隊規模不大、以及開發時程不長的軟體專案而言，軟體工程卻又太複雜了。於似乎有人認為不應該拿「軟體工程」來比喻軟體專案的開發過程。例如《软件工艺 Software Craftsmanship》這本書，提出了軟體工藝的新隱喻。而我有一位學長喲哪桑也發表了他看此書之後的心得感想。

喲哪桑認為「軟體工程」雖然可以幫助我們了解與學習軟體開發，但它卻並不等於軟體開發的本體呀。學長認為「軟體工藝」可成為一個新的隱喻、新的tag，從極致的工藝技術來比擬軟體開發。如此，關鍵將落在於重視軟體開發者的技能、經驗與才華。換句話說，他認為是人的能力左右了軟體的成敗而非工具與技術。

所以，軟體開發是工藝乎？喲哪桑也不敢驟下斷言，但他認為，可以選擇少把 process compliance 掛在嘴邊，而多談 PSP 及 TSP，回歸「以人為本」的軟體開發。而獨孤木看了學長所發表的心得，也提出他對軟體開發的看法，他則認為軟體工程的大部份理論，都是導源於開發軟體時，有很多人需要一起合作，所以需要建立共同的溝通方法與管道，以及一些共用的工作紀律。所有的軟體工程理論，其實都只是在告訴你，在人數眾多時，應該要遵循什麼樣的開發方式，才可以避免或解決他們所面臨的問題。

換言之，軟體工程的目的是提供一種開發方式，讓軟體開發的工作，能做適度的分工，同時也讓開發者之間的溝通，能夠順利進行，以避免或解決在軟體開發過程中，可能會遭遇的問題。然而，站在軟體工藝的角度而言，對於軟體規模不大、參與開發的人數不多、開發工期不長，對於技藝超群的開發者而言，根本就不需要考慮分工及與其它開發者溝通的問題。只要他能夠把客戶想要的軟體做出來，一切問題都會得到解答，是嗎？

有了這樣的推論，我們可以假設軟體開發是工藝，可是，依同人實務上的觀察，問題好像沒有那麼簡單，尤其是要「把客戶想要的軟體做出來」，說起來簡單，做起來卻很困難。雖然減少了開發者之間了的溝通界面，但這樣一來，開發者就必須直接和客戶溝通來導出客戶需求。開發者往往會發現，即使和客戶直接溝通，在導出軟體需求的過程還是會出現需求導出的三大障礙[ref]Dean Leffingwell & Don Widrig (2003), Managing Software Requirements: A Use Case Approach, Second Edition, Addison Wesley Professional.[/ref]，那就是客戶常常不知道他們真正需要的是什麼、永遠會有需求被遺漏、開發者與客戶或使用者之間的不同背景或語言而導致溝通不良。

所以，如果開發者與客戶之間缺乏足夠的溝通，即使開發者擁有精良的工藝技術，但還是無法開發出客戶真正合用的軟體，有時候開發者會不知所託－不知道客戶真正需要的軟體是什麼；有時候開發者會所知非託－習於用技術來主導客戶或使用者的需求，不管是那一種現象，其結論都會一樣－最後必然導致專案失敗。

於是，為要解決導出需求的第一大障礙，開發者通常會應用使用界面雛型、系統展示來與客戶確定需求、用反覆及漸增開發方式來逐步開發並演化系統；要解決導出需求的第二大障礙，則以小心謹慎的方式進行驗證與確認；至於要解決導出需求的第三大障礙，如果開發者及客戶無法以開放的心胸來接納不一樣的觀點的方式，進行良性溝通，就必須在開發者與客戶之間尋求中介角色以增進溝通效率，甚至將開發工作做適度的任務分工。以上做法，都是常見的軟體工程實務，所以，在實務上，軟體開發是工程。而事實上，大部分軟體工程的理論都是源自軟體開發的實務而演變出來的呀[ref]同人曾聽過黃世禎老師主張過這個觀點。[/ref]。

其實，軟體開發其實不同於一般傳統製造業的生產，在軟體產業中，軟體的複製與配置才是真正的製造程序[ref]請參考曾昭屏譯（2006），溫伯格的軟體管理學，經濟新潮社，初版。[/ref]，因此軟體開發本質是設計（的服務）而非製造。而從另一方面來看，軟體要解決的問題和傳統製造業也有很大的差異，當我們建造一棟房子、車子或遊艇時，問題對我們而言是很確定且易於掌握的，也不需要結合跨領域的專業。

但軟體卻不一樣，企業資訊系統常常是為了企業因應環境變化，所造成的挑戰與威脅，而設計出來的整合解決方案。所以不同產業的軟體系統，常常會需要該產業與資訊產業的跨領域整合，其問題複雜度及不確定性是高出一般製造業甚多的。關鍵不在於如何生產，而在如何使企業能夠面對複雜的環境變化。所以，同人認為，軟體開發的本體並不在工藝，也不在工程，而是一種問題解決的過程。

當我們了解軟體開發其實是一種問題解決的過程後，另一方面，我們的若干經驗也告訴我們，問題變化的本質是複雜的，期待需求不會改變其實是不切實際的，我們應該擁抱改變以適應變化。

同人看過一篇 Peter Ho 在點空間討論區所發表過的一篇文章，正說明了從簡單演進到複雜，其關鍵在於混沌邊緣（the edge of chaos），也就是界於穩定與穩亂之間的過渡地帶，而系統會自我組織並且演化出複雜的行為。此篇文章提出有關學習曲線的不同觀念，那就是我們不應該為有秩序的需求而奮鬥，那是千年以來錯誤的觀念。演進本身不需要小心建構，也不需要工藝，取而代之的是在秩序與混亂之間，彼此互動元素稀疏相連的極致複雜網絡。只有在過渡地帶附近的混沌邊緣，那裡將會發生最複雜的行為：具備足夠的秩序以保持穩定，卻充滿彈性與驚奇，這也就是所謂的複雜性的重要概念。

Brace yourself, here comes a big impact of learning curve:Our intuitions about the requirements for order have, I contend, been wrong for millennia. We do not need careful construction; we do not require crafting. We require only that extremely complex webs of interacting elements are sparsely connected… Just between [order and chaos], just near this phase transition, just at the edge of chaos, the most complex behaviors can occur – orderly enough to ensure stability, yet full of flexibility and surprise. Indeed, this is what we mean by complexity. – Stuart Kauffman, At Home in the Universe, p84 and p87.

複雜性並非靠預測，而是靠演化。或許我們真的弄錯方向了，在軟體開發方面，用軟體工程的小心建構或是軟體工藝的工藝技術都沒辦法讓軟體能夠適應變化解決日益複雜的問題，所以，軟體開發的本體，應該是開發可以隨著環境變化而演進的系統，這也就是，Peter Ho 在點空間的另一篇文章所提到的「複雜適應性系統」（CAS）的觀念：讓系統自己組織起來到混沌邊緣，那兒將會使共同演化發生。但軟體開發要如何讓系統自我組織呢？Peter Ho 認為，未經重構，系統將會沒有空間來容納新功能來適應新的變化驅力；未經測試，開發者不會知道系統邊緣在那裡；未經整合，生命火光將逐漸消散。

Organizes itself to the edge of chaos where co-evolution happens. – Complex Adaptive Systems (CAS)Without refactoring, there is no room for plugging in new functionality to adapt the coming force.

Without testing, we couldn’t know where the edge is.

Without integration, the spark of life will die out.

As quoted by Kauffman, there are three things that allow a system to get to the edge of chaos and stay there:

It has to be confined to a small portion of the vast space of possibilities.

It has to be stable enough that it doesn’t disintegrate into chaos when the slightest change happens.

It has to be balanced between statically dead and the hyperactive “chaotic regime.” [Chaordic]

What we end up with in Kauffman’s world is a set of self-ordered adaptive agents, exploring their way through a vast space of possibilities, with stable flexibility that allows novel “leaps” to new fitness peaks. The specific outcome is unpredictable, and undirected. In Kauffman’s view, Darwin wasn’t wrong, just simplistic and incomplete…Thinking about software development as an effort to grow something, instead of as an effort to manufacture something. – Roy Miller, Managing Software for Growth, Ch6 – Order for Free.

Peter Ho 並引用 Kauffman（著名生物學家兼複雜系統研究者）的觀點指出，有三件事可以讓系統到達混沌邊緣並且停留在那裡，那就是：必須把廣大的可能性限制在一小部分、必須保持足夠的穩定，即使有輕微的改變，系統仍不會崩解成混沌一片、以及必須在靜止不動的死寂與過度活動的「混亂政體」間達到平衡。

最後，Peter Ho 告訴我們，從 Kauffman 的世界觀來看系統，是一套自我維持秩序適應的代理者，從可能性的廣大空間探索他們的途徑，藉由穩定的彈性，允許新穎的「跨躍」，以適應新的高峰。特定的結果是無法預測的，並且是無從指導的。當然，Darwin 並非錯了，只是過分簡化及不完整。而以軟體開發的角度來看，不要把軟體開發思考成為製造一些東西而努力，而是要思考為成長一些東西而努力。

所以，關鍵不在核心，而在邊緣。找到混沌與秩序的交界點，停留在那裡，讓自我組織與突現能不斷地發生，自然演化出系統的複雜行為，所以，系統複雜性無法靠預測、指導出來，而是系統自行依據環境變化，自然而然地演化出來的呀。

雖然，複雜理論的觀念或許太新，並不是那麼容易讓人接受。但身為軟體開發者，可不要忘了，軟體開發中，不同知識的整合卻攸關了軟體開發的成功與否。誠如同人在〈你憑藉什麼知識來「做」專案呢？〉中所說的：

稱職的專案經理所憑藉的是運用專案管理的專業知識整合軟體開發經驗知識與使用者現場知識，而專案管理知識最難掌握的是人的問題。

其實每個人都是某項特定知識的載具，若軟體專案的 stakeholders 之間，未能做有效的良性互動，知識就不可能相互激盪而產生火光，調適出適當作法而為專案產生出創意及價值。此時，工藝技術只是工藝技術，工程流程只是工程流程，它們都會跟軟體開發沒有任何關係，變成只是片面的零散知識。所以，不管軟體開發是工藝還是工程，最重要的還是讓不同觀點能夠適當的運用、調整與熟練，這才是優秀的軟體開發者應有的態度呀。

Please follow and like us: