有一種工程師的職稱叫 Software Constructor(或是類似)，通常是專業的軟體公司才有(而且要夠大)，這種職務通常是非常有經驗的工程師轉任，在軟體建構中擔任非常吃重的角色，雖然不用去實做程式碼，但卻擔負了軟體成敗最大的責任，Constructor除了對軟體設計必須有很深入的認識外，對市場需求性及使用者行為更需要有獨到的見識，尤其是當軟體是開發給一般大眾使用時。
大多數中國或台灣的軟體開發業主，都是由企畫提案，通過後就由這個企畫在PPT上畫個草圖，然後就丟給工程師去實做，而且希望工程師能夠通包人機介面與軟體功能，通常透過這種模式開發出來的軟體，十之八九都賣不出去，雖然我不想承認，但寫過多次這種案子，結局都是....業主賣出的套數，指頭數得出來...
一般企畫其實都不知道自己"正在"擔任Constructor的工作，只是一昧的想把自己的想法經由工程師去實現，卻不具備Constructor的專業知識，而一般工程師也是抱著業主要什麼就寫什麼，賣不好是他家的事，尾款有付就好的心態去寫程式，不大可能有工程師會說...你這東西寫出來不會有人買啦..之類的話，結果...曇花就這麼每天開一下...
Construtor通常（幾乎是必須）由工程師來擔任，一個善於開發軟體的工程師，對使用者行為會有一定程度的瞭解，也就不會陷入所謂功能迷思（功能越多用戶越多），或是太監的憂鬱（皇上可能會需要...）等等陷阱
對行為科學有研究的人也很適合擔任Constructor，但在技術面上就稍嫌薄弱，若在完全沒有知識技術背景的情況下，軟體開發的主導權就會落在實做工程師的身上，最常見的狀況就是工程師為了要快速結案，只求軟體能RUN，不可能會去執行Constructor的工作（即使具備這種能力）
最常見的企畫案就是開發某種軟體來取代傳統作業，也就是所謂E化，然而許多企畫人員往往不瞭解E化的本質，認為什麼事只要變成軟體就叫做E化，其實E化的本質非常簡單，就是將繁雜的工作，利用軟體工具簡化成單純、容易理解與操作的工作，而失敗的E化，卻是反其道而行，將原本簡單的工作複雜化，如以前的便利商店有賣所謂家庭式會計的套裝軟體，試想一個媽媽原本用紙筆跟計算機就能做的事情，有什麼理由必須使用軟體呢？...當然這套軟體也是一盆曇花...
我寫過不少失敗的"E化"軟體，最常聽的就是某某功能該怎麼樣，因為怕使用者怎麼樣....我其實很想說...不用擔心啦，使用者大概就你一個...
其實寫久也就麻痺了，反正台灣的業主都是"大錢花不起、小錢燒不完"
有點離題....
Constructor主要的工作就是評估一個軟體的市場需求性（研究同性質軟體及可利用的核心），在技術面上他必須規劃出軟體的架構，如物件規劃（物件規劃得好甚至可以單賣此物件給軟體公司），在程式碼上，使用何種設計模式，讓軟體擁有高擴充性，高再利用性等等，這需要長時間軟體經驗的累積，當然整體的開發期也就越長，除非價格夠好，不然即使有能力的工程師也不會這樣做。
擔任這樣職務的人，其薪資報酬不是一般中小企業所能負擔的，所以往往就變成企畫兼任，，有些企畫當專案進行到一半，突然覺得不可行時也無法回頭（難道要自掏腰包給工程師），硬著頭皮做下去，結果當然......（反正賠錢的是公司，自己大不了走人換頭路）
