ソフトウェアの仕様書は料理のレシピに似ている
とても共感しました。

やはり「よい設計」をするには、プログラミング経験があることが必要だと思います。
そこそこの設計であれば、プログラミング経験が少ない人でも可能とは思いますが、やはり近道はプログラミング経験を積んでいることだと思います。

加えて、SEとして設計するようになっても、継続してプログラミング（実装）に触れていることが必要だと思います。
私の周りにいる人。
本当は開発好き。なれどPG→SE→PMと王道を歩んで、プログラミング技術は一昔前の知識になってしまった人。
実装寄りの考え方を持っている点は、すばらしいのですが、俺流の古臭いアイデア技術をうれしそうに設計するのがちょっと困りもの。
いや、古いのは悪くないんですが、すでに新技術として定着しているものを俺式に再発明しちゃうのが困る。
「俺が考えたこの方式ならば完璧っ！」って感じに、古い実装案をわざわざ考えてくれる。

記事の内容には非常に同感するのですが、悲しいことに、ウチの会社はそれに完全に逆行しています。

• プログラミングなどの実装は外注、海外に委託しようぜ！
• 自社では、上流の設計と外注管理が出来る人を育てますから！
• プログラミングの勉強？そんなの今後は外注の仕事だから、そんなの学ぶのはやめとけ！

大体こんな感じ。設計する人は実装を知らずに設計するし、「コミュニケーションの取れないオフショア外注」に丸投げするのを理想的に考えているから、恐ろしい。。。
設計できる人が、どんどん先行して設計していき、追っかけで大量の実装部隊がモノを作り上げていく。それを目指しているんでしょうが、実際のところ、そんな感じにはなっていないです。
恐ろしいなんて言っている場合じゃなく、正しい方向に自分が向かわせるべきなんですが、担当が開発から少し離れてしまっているので、ちょっとそんな元気も今はないです。

以下は、記事からの引用

プログラムの仕様書は料理のレシピに似ている。ソフトウェアのアーキテクトが自らプログラムを書いたり、下っ端のエンジニアの書いたコードをレビューするのは、レストランのシェフが自ら料理をしたり、下っ端の料理人の作ったスープの味見をするとの同じである。もちろん、レストランに行く側の立場になってみれば、そんなレストランで食事をしたいのは当然である。シェフがレシピだけ書いてキッチンにも立たないレストランには行きたくないし、ましてや自分で料理したこともないシェフが書いたレシピを元に作った料理がおいしいわけがない。

レシピという言葉を借りれば、
レシピだけでは料理の詳細を、調理担当者に正確に伝達することはできないわけで、レシピを正確に実現できるのは、レシピをつくったシェフですね。
SEの作った詳細設計書だけでは、プログラマに正確に伝達することはできないわけで。