儘管我很看好網路經濟，但是仍然有許多令人擔憂的地方，這些問題也同樣存在於其他的大型、去中心化的自為 系統中。
它們很難被理解
它們不太容易受控制
它們並非最優化的
當各種公司取消實體進入某種巴洛式的賽博空間之後，它們就具有了某種類似於軟體的特點。無污染、無重量、快速、有用、可移動而且有趣。但同時也可能變得非常複雜，充滿了沒人能查明的煩人的小毛病。
如果未來的公司和產品就跟現在的軟體一樣，那意味著什麼？會破碎的電視機？突然熄火的汽車？會爆炸的烤麵包機？
大型軟體程序可能是人類現在所能製造的最複雜的東西了。微軟的新操作系統有4百萬條代碼。當然，在7萬個Beta版本的測試點進行測試之後，比爾蓋茨肯定會說，現在這個軟體沒有漏洞了。
那麼，我們是否可能製造出那種超級複雜而又沒有任何缺陷（或者，只有很少幾個缺陷）的東西來呢？網路式經濟到底是能幫助我們創造出一種沒有缺陷的複雜系統，還是只能為我們建立一個有漏洞的複雜系統？
不管各種公司自己會不會變得更像軟體，至少，它們所生產的越來越多的產品肯定會依賴於愈加複雜的軟體，所以說，創造沒有缺陷的複雜系統是絕對必要的。
在模擬領域，驗證一個模擬的真偽，與測試一個大型複雜軟體是否有缺陷是同一類問題。
加拿大計算機學家戴維·帕那斯 曾經對里根的星球大戰計畫提出了8條批評意見。他的觀點基於超級複雜軟體內在的不穩定性，而星球大戰計畫恰恰就是這麼一種超級複雜的軟體。戴維·帕那斯的觀點中，最有趣的一個是指出存在兩種類型的複雜系統：連續的和非連續的。
通用汽車公司在測試新車應對急彎的性能時，會讓這輛車在不同的時速下進行測試，譬如50、60、70英里。顯然，性能隨時速的變化是連續的。如果一輛汽車能夠在時速50、60、70英里的時候通過測試，無需測試我們就會知道，在各種中間速度——比如每小時55或者67英里——的時候，它也肯定能通過測試。
他們不用擔心這輛車以每小時55英里的速度行駛時會突然長出翅膀來或者翻個底朝天。它在這個速度上的性能，基本上就是它在50英里和60英里時性能的某種插值。一輛汽車就是一個連續的系統。
計算機軟體、分散式網路以及絕大多數的活系統都是非連續的系統。在複雜的適應性系統中，你根本不可能依賴插值函數來判斷系統的行為。你的軟體可能已經平穩運行了好幾年，然後突然在某些特定的值點（比如，每小時63.25英里），轟隆一聲系統爆炸，或者，突變為某種全新的東西。
斷點始終都存在著，而你已經測試到了所有的鄰近取值，卻沒有測試到這特別的一組環境值。事情發生後，你會一目了然為什麼這個故障會導致系統崩潰，甚至能明白地指出為什麼人們本該找出這個隱患。不過，這都是事後諸葛亮。在一個擁有海量可能性的系統中，根本不可能對所有的可能性進行測試。更糟糕的是，你還不能依靠抽樣的方式來對系統進行測試，因為它是非連續的系統。
對於一個超級複雜的系統來說，測試者沒有任何把握說那些沒測試到的值就一定會和抽樣到的數據之間呈現一種連續關係。不過，儘管如此，現在還是出現了一個旨在達到「零缺陷」軟體設計的運動。不用多想，這個運動肯定又是發生在日本。
對於小程序來說，這個「零缺陷」的零就是0.000。但是對於那種超大型的程序來說，這個「零」指的就是小於等於0.001。這是指每千行代碼允許的錯誤值，而這只是產品質量的一個大概標準。這些旨在編寫零缺陷軟體的方法，大量借鑒了日本工程師新鄉重夫的零缺陷生產的開創性工作。當然，計算機科學家們聲稱，「軟體不一樣」。軟體可以被完美複製，因此只需要保證最開始的那一份是「零缺陷」就好了。
在網路式經濟中，研發新產品的費用主要源自生產流程的設計，而非產品設計。日本人擅長生產流程的設計和改進，而美國人擅長的是產品的設計和改進。日本人把軟體看作一個生產流程而不是產品。在漸露端倪的網路文化中，我們所生產的越來越多的東西——當然也是我們越來越多的財富——都與符號處理流程密切相關，這些流程所裝配的是代碼而非實物。
軟體可靠性大師C.K.曹曾經告誡業界人士，不要把軟體看成產品，要把它看成攜帶型工廠。你賣的，或者說，你給予客戶的是一個工廠（程序代碼），可以在客戶需要的時候為他製造出一個答案。你的難題是要製造一個能生產零缺陷答案的工廠。建造能夠生產出完美可靠器件的工廠的方法，也可以輕易地應用到創建能給出完美可靠答案的工廠上。
通常，軟體的編製遵循三個中心化的關鍵步驟。首先設計一個全景圖，然後用代碼實現細節，最後，在接近項目尾聲時，將其作為交互的整體來進行測試。而在零缺陷質量的設計流程中，整個軟體編製過程不再是幾個大的關鍵步驟，而是被分散成上千個小步驟。軟體的設計、編寫和測試工作每天都在成百個小工作間里進行著，每個小工作間里都有一個人在忙碌著。
這些零缺陷的傳道者有一個概括網路式經濟的口號：「公司里的每個人都有一個客戶」。通常而言，這個所謂的客戶，就是你的工作夥伴，你要將工作依次轉交給他。而你必須首先把你的那個小循環（設計-編寫-測試）做好，才能把它交付給你的工作夥伴——就好像你在銷售商品一樣。
當你把你的工作成果交付給你的客戶/工作夥伴的時候，他/她就會立刻對它進行檢測，並把其中的錯誤反饋給你，讓你進行修改，讓你知道你的這份工作完成的到底怎麼樣。從某種意義上來看，軟體的這種自下向上的發展過程與羅德尼·布魯克斯的那種包容結構本質上並無不同。每個小步驟都是一個小的代碼模塊，能確保自身的正常運行，在此基礎上，人們疊加和測試更複雜的層級。
單靠這些小步驟並不能得到零缺陷的軟體。「零缺陷」的目標隱含著一個關鍵的概念區分。所謂缺陷，是指被交付出去的錯誤；而在交付之前被修正的錯誤，不能算是缺陷。按新鄉重夫的說法，「我們絕對不可能避免錯誤，但是我們可以避免錯誤成為缺陷」。因此，零缺陷設計的任務就是儘早發現錯誤，儘早改正錯誤。
不過，這是顯而易見的事情。真正的改進在於儘早發現產生錯誤的原因，並儘早清除產生錯誤的原因。如果一個工人總是插錯螺栓，那就設置一個防止插錯螺栓的系統。犯錯的是人，處理錯誤的則是系統。
日本人在防錯領域的經典發明是一種稱為Poka-Yoke的防錯系統 ——它可以使事情對人們所犯的錯誤具有「免疫力」。在裝配線上設置一些巧妙而簡單的裝置就可以防止錯誤的發生。比如，在放螺栓的托盤上為每一個螺栓設定一個特別的孔位，這樣，如果托盤上有螺栓剩下，操作人員就知道自己漏裝了一個。在軟體生產中，有一種防錯設計是「拼寫錯誤檢查器」，它不允許程序員輸入任何拼寫錯誤的命令，甚至不允許他/她輸入任何非法（非邏輯）命令。軟體研發人員們有越來越多可供選擇的非常精巧的「自動糾錯程序」軟體，用來檢查正在編寫中的程序，以防止典型錯誤的出現。
還有那些頂尖級的研發工具可以對程序的邏輯進行分析和評價——它會說，「嘿！這一步根本沒意義！」，從而在邏輯錯誤一出現的時候就將其清除。有一本軟體業的交易雜誌最近列出了近百種檢錯和改錯工具，沽價待售。其中最精緻的一種還可以像那些優質的拼寫檢查軟體一樣，為程序員提供合乎邏輯的改錯選擇。
另外一種非常重要的防錯方法是對複雜軟體進行模塊化。1982年發表在IEEE的《軟體工程交易》上的一個研究顯示，在其它條件完全相同的狀況下，代碼總行數相同的程序拆分為子程序之後，錯誤數量是如何減少的。一個1萬行的程序，如果是一整塊，它有317個錯誤，如果把它拆分為三個子程序，那麼總數還是1萬行的程序，錯誤數則略有減少，為265個。每拆分一次所減少的錯誤量，大致符合一個線性方程，所以模塊化雖然不能完全解決問題，但它卻是一種有效的手段。
進一步來說，當程序小到某個閾限以下之後，就可以達到完全沒有錯誤的狀態。IBM為它們的IMS系列所寫的代碼，就是以模塊化的方式編製的，其中有四分之三的模塊達到了完全沒有缺陷的狀態。具體來說，就是在425個模塊中，有300個是完全沒有錯誤的。而在剩下的125個有錯誤的模塊中，有超過一半的錯誤集中發生在僅僅31個模塊上。從這個意義上說，程序編製的模塊化，就是程序的「可靠化」。
在軟體設計領域，現在最熱的前沿就是所謂「面向對象」的軟體。