結果はいつ欲しい？

ここのところずっと「ユースケース駆動開発実践ガイド」という本を読んでいるのですが、これまで提案されて来た UML による設計手法をより自動化するための方法論が書かれているのですが、個人ベースでのプログラミングを頭に思い浮かべると、いろいろ辛い点が見えてきます。テスト駆動開発でもそうですけど、結局ちゃんと目に見えて動く物が出来上がり始めるのはかなり最後の方なんですよね。そこまでモチベーションを保つのは結構しんどい。これはそこそこ小規模なチーム開発でも同様のことが言えるのではと思います。

せめてロバストネス図を最初に書いたあたりの所で、いったん設計の手を休め、動くものを少し作ってみて、その動作から多少のフィードバックを得る、というようなユーザインタフェースの側からの方法論も盛り込むべきなのでは。

これまで「print a + b」などと書いては実行して来たプログラミングが、より抽象的な枠組みの中でまず捕捉されるわけですから、ある程度は仕方ないわけですけど。

あと結構この本にはいささか矛盾があって、「ここまで設計を綿密にやってきたのですから、論理的などいかなる飛躍のありようもありません」と書いた15ページ後ろで、「ここでの目的は、論理的な飛躍を徹底的に取り除くことです」と書いてあったりね。どうも本当に理想的に自動化できない部分は、これまでの UML 関係の本と同様、誤魔化している感が否めません。