現今有許多方便的技術，入門學習起來不費功夫，甚至用來作為解決方案，乍看也蠻像一回事，因而產生了許多目標導向的作法。
例如，過去熱門的課題，是以打造一個部落格為目標，而現在可能是行動裝置App。從中遇到什麼問題，就克服什麼問題，某些方面這是不錯的作法，然而，某些方面，這也會引發一些問題！
來個輪胎設計營如何？
這些日子以來，因為熱衷於使用OpenSCAD進行程式建模，分享了不少作品，也發表了一些文件記錄我的設計思路與零星想法。
由於在（臺灣）3D列印這領域，使用程式建模的人極少，自然地，我的作品與文件容易突出而引人注意，因此，除了演講與邀稿之外，也開始有人想要合作協商課程，而其中一個特別的課程是輪胎設計營的構想，對方希望可以教導學生使用OpenSCAD，來進行輪胎建模，而且，為了讓輪胎有彈性及抓地力等因素，列印時會採用軟料，同時，對方可以提供我軟料測試。
我對後者回應是：「軟料不用給我」、「列印與測試軟料離我的專業太遠了」而對前者的回應是：「我擔任的角色，應該是在教會你們運用OpenSCAD，而不是教會你們設計輪胎……我對輪胎沒有概念」。
輪胎設計營是其中一個例子，另一個課程也很有趣。對方提出的問題是：「有無可能設計課程來教導列印一些古老部落重複型圖示？例如台灣原住民的衣服？」而我的回應是：「只要有重複的模式，基本上就可以設計，但是你們要告訴我那個模式是什麼，因為那些未必是我研究過的東西」。
如果你從未接觸過自造者（Maker）領域，這兩個題材看來似乎很新鮮，實際上，回到軟體設計領域，這種情況也很常見，只不過主題換成了某種類型的Web應用程式，或者是行動裝置App，而且大多會是希望從語言開始，最後產出一個應用程式作為結果。
當程式設計遇上……
至今為止，我沒有寫過任何一個行動裝置App（我常戲稱對它沒有愛），因此，我推辭任何有關行動裝置App的課程設計。
實際上，行動裝置App的書籍相關資料非常地多，我大可以臨時趕鴨子上架地惡補幾本，不足的部份，以一些通用的程式設計概念彌補，然後再加上點個人名聲，也許就能讓學員信服。硬是要承接課程的話，某些程度上，還是能蒙混過關的。
輪胎設計營？我對輪胎根本一無所知，重點是我去哪找輪胎的資料啊？對方丟給我Thingiverse上的一些輪胎模型，作為參考，我隨便擺弄了幾個，用OpenSCAD畫了個看似輪胎的東西，事實上，我知道這根本就不是輪胎，天曉得它的曲線是不是對的，上面的輪紋是純粹的裝飾，還是有實際的作用？裝到遙控車上時，輪框帶得動這輪胎嗎？或者只是輪框搞笑地自轉而已？
至於古老部落重複型的圖示，我也沒研究，因此我第一個想法是：「你們要告訴我重複的模式是什麼，而不是丟一個東西，請我自己探索重複的模式是什麼，因為每個人研究的東西不同」。
重複，看起來沒什麼難的，對嗎？其實，如果實際研究過禪繞或是碎形，就會知道沒那麼簡單。
因為，重複有很多種——水平或垂直位移、旋轉，或者各式的組合。古老部落重複型的圖示？嗯！光是搜集資料，或辨識重複樣式，就會耗費我很大的時間。
好吧！當程式設計遇上Web應用程式，可以寫些無關痛癢的應用程式，像是討論區之類的；當程式設計遇上行動裝置App，也可以寫個無關痛癢的BMI計算之類的。那麼，當程式設計遇上輪胎設計，我也可以設計個像是輪胎的東西；當程式設計遇上古老部落重複的圖示，我也可以隨便教教海龜繪圖、遞迴，畫畫科赫曲線、蕨葉曲線之類的。不過，這真的是課程提案者，或者是學員想要的東西嗎？
課程提出者其實都很有誠意溝通，純粹只是誤以為我，也研究過這類型題材，不過，其實我也因此想到了一些值得思考的問題。
對本質性困難的誤解
如果對軟體設計有一定時間的浸淫，也許就會看過《人月神話》作者Frederick P. Brooks，在1986年發表的論文《沒有銀彈：軟體工程的本質性與附屬性》，而我曾經在先前專欄〈框架的本質與附屬〉中，對於本質性與附屬性作過介紹。
簡而言之，在軟體設計界中，越來越便利的語言、程式庫、框架與工具等，讓程式設計者越來越能免於附屬性困難，以便集中心力在解決問題的本質性困難。
自造者運動再興以來，也已經若干年了，而這些年來，我發現，越來越多便利、門檻低的自造工具，不斷地被創造出來，像是控制板、感應器、可程式機器人、3D列印機等，這些工具讓想要自造某物的過程中，附屬性的困難降低，也成為用來吸引更多人加入自造的號召口號之一。
然而，你就會發現，不只是軟體界會有百花齊放的情況，自造界也是如此。三不五時地，就會看到，又有人熱切地討論哪個新控制板、感應器出現了……嗯……感覺就像是不斷地在重複「下一臺XXX會更好」這樣的話……
其實，無論工具再怎麼方便，問題的本質性困難仍是不變的。
回到程式建模，也是一樣，對於有重複規則的模型，是可以使用程式建模來更方便的解決；不過，它也有其本質性的困難——如果要描述一個曲面，得找出它的數學函式；如果要建立重複的圖樣，得辨識出它的重複模式；而像OpenSCAD選擇了函數式風格，於是，這也成了它在描述模型時的本質性困難之一。
在過去，無論是軟體界或是自造界，由於問題的本質性與附屬性困難程度，相當地交錯在一起，很難辨識出兩者。而現在，新工具的推出，降低了附屬性困難，卻往往給了我們本質性困難也一同降低了的感覺。
我觀察到，許多推廣者或課程設計者本身，常有這樣的誤解。為了吸引更多人加入，雖無可厚非，然而，對於本質性困難，特意避而不談，或甚至無法察覺，也並不是個正確的做法。
跨領域學習時的誤區
對我來說，輪胎或古老部落重複型圖示很陌生，因而本質性困難是顯而易見的。至今我也未正式承諾設計這類課程，同時，我也跟對方表達這類觀點，因為，這是跨領域學習時的誤區。
程式設計本身，也有其學習上的本質性困難，需要克服；輪胎，或古老部落重複型圖示也是。在此同時，我也請對方想清楚，想要學員習得的是哪個部份？
當然，很多人兩者皆想要，可惜這很難達到。就這方才兩類型的需求來說，必須找到另一個人能教授輪胎，或古老部落重複型圖示的知識，而如何能克服OpenSCAD在程式建模上的本質性困難，由我教授；除此之外，還需要考量課程時間長短，以及學員程度是否能吸收等要素。
也就是說，如果工具真的太方便了，學習就更應重視而非輕視本質性困難……
以我最近的例子來說，我對資料科學產生了些興趣，使用的工具是Python，結果怎麼了？至今為止，我花費最大量的時間，是在向量、機率、統計等學習上。
為什麼如此？因為，Python我算是很熟悉了，相關資料科學工具，看來也非常豐富與方便，真是太好了。這表示，我可以專心地學習資料科學處理需要的一些數學，並且，進一步看清，哪些才是解決本質性困難時有所助益的相關知識。