引述自 Adam Barr 在 MSDN 的專欄文章：
我還是大四的學生時， 我記得有一位即將到投顧銀行上班的電腦科學系同學所說的話。他表示他只會參與軟體的設計，但是不會實際加入程式碼的撰寫工作，因為那太無趣。如此的工作應 該要交給程式撰寫人員 -- 顯然他認為程式撰寫人員是身分比較低等。當初那指的當然就是我囉。如此的談話發生在一所破解程式碼是最高榮耀的大學而言，讓我感到被羞辱的情緒。
然而，他也沒說錯。當初我只是一名程式撰寫人員 (雖然他的程式撰寫能力不見得比我好)。如今，就像 Mike Gunderloy 的書 Coder to Developer 所示，我已經從一般的程式撰寫人員晉升到開發人員。我不但知道如何撰寫可以順利編譯的程式碼；我創造的軟體產品還可以有：執行速度敏捷、可靠、通過完善測 試、安全、可維護性佳且易於全球化…以及其他高品質程式碼應有的特點。一般而言，整個軟體產業的龐大程式編寫人員組織，正在成長與演進為龐大的開發人員組 織。但是，如果您詢問開發人員專業生涯的下一步，他們的答案 可能會是想要成為「架構設計人員 (Architect)」。所謂的「架構/結構設計」會令人聯想到鈦合金骨架和毛玻璃，而且相對的會把開發人員的身分影射成營建工人的角色。那麼我是否也 想要躍升到下一個理論性的階層，讓自己成為架構設計人員呢？答案是否定的。
這並非因為我瞧不起架構設計人員的職責：在軟體開發過程中協調所有系統元件的互動，同時考慮到整體目標 – 這的確需要有人擔任。然而，身為開發人員我深感榮耀，而且我也誠懇地希望每一位開發人員都能感受到這樣的榮耀。
但是萬一有人仰慕實體架構設計師 Frank Gehry 或 Rem Koolhaas 在設計上享有的知名氣和自由度呢？我的回應會是，軟體工程設計的領域目前還不夠成熟，無法以這麼概念性的方式運作。架構設計人員可以設計如 Bilbao Guggenheim Museum 以及 Seattle Public Library 等的之名建築物，因為土木工程的領域已經累積有數百年的知識和經驗做為基礎和後盾。但是軟體產業無法一下子讓所有人都晉升到這個層次；畢竟我們大多數都還 在建構一棟不會在用力甩門既倒塌的平房。
當Microsoft 檢查程式的錯誤 (Bug) 時，發現設計性的錯誤 (亦即，架構設計人員審閱設計文件時會發現的錯誤) 佔據的比率很低，而且程式編寫錯誤 (亦即，程式碼無法根據程式設計人員的用意執行) 的比率也不高。會產生居中的類別，是因為雖然來源程式碼可以根據程式設計人員的用意執行，但是用意在進行當地語系化時發生錯誤 (應譯為：但是這些用意有些區域性的錯誤)：問題包括傳遞給方法的旗標有誤，或是曲解了組態參數的意思。而這些都不屬於架構設計人員可以處理的領域。這都是開發人員必須自行修正的事項。
Fred Brooks 在他的著名文章 “No Silver Bullet” 中有間接提到這項重點：「軟體的本質涉及連鎖概念的結構：資料集、資料項目的關係、演算法，以及函數的呼叫」，其中還包括：「我相信建構軟體最困難的部 分，在於擬定這些連鎖概念的詳細規格、設計以及測試，而非結構的呈現或精確度的測試。」由此可見，他認為關鍵並非在於結構設計人員，而是開發人員的工作。 換句話說，他認為程式編寫人員的工作不是很困難，但是開發人員的工作就有許多挑戰。因此，我們應該要肯定我們的價值。
我知道或許我們的工作不是整體程式設計的最高層次。能夠設計完美的結構，以精簡地封裝所有變數並因應未來的擴充需求，的確是一件令人振奮的成就。畢竟程式設 計人員都講求精確度，所以能夠讓所有組件順暢合併就是理想。但是軟體的創造其時有很多部分需要我們向熟練的工匠看齊：例如程式碼的審閱、撰寫單元的測試， 以及註解的清理。客戶或許無法直接認定是我們的辛勞，才能確保他們的隱私以及系統的防禦，但是我們都知道我們所提供的價值和重要性十足。此外，若要最佳化系統效能和電源管理，更需要黑手藝術的真材實料：這需要近距離接觸、以技能和經驗解決問題的實力，而非高階概念性的結構設計所能。
我要大聲說：身為開發人員而非結構設計人員是我的榮幸。或許在未來的某一天，所有的軟體工程問題都將獲得解決，讓我們都可以成為結構設計人員。在此之前，我們還是專注於如何持續加強軟體開發吧。