Thoughtworksのコンサルタントであり、作家でもあるMartin Fowler氏はyagniの法則について説明し、なぜこの原則が重要なのか、仮定の機能を作ることのコストについてブログに書いている。Yagniは、頭字語であり、"You Aren't Gonna Need It"の頭文字をとっている。エクストリームプログラミング(XP)の実践であり、プログラマは必要になるまで機能追加をしない、ということだ。
XPの創立者であるRon Jeffries氏は次のようにいう。
必要になった時に実装します。必要になるだろうと予想したときには作ってはなりません。
Cunningham & Cunningham wikiによれば、
ある機能が後に必要になると確信しても、今、実装してはなりません。そのような場合は、普通は、全く必要ない機能か、または、実際に必要なものは、必要と予想したものとはかなり違うものになるでしょう。この原則を実践する理由は主にふたつです。
- 時間節約。不要なコードを書かないようにするため。
- コードを良くするため。多かれ少なかれ間違っている'予想'コードに汚染されないように。
Martin氏によれば、推定に基づく機能を考えるとき、それは間違っているものだ。そのような機能の明らかなコストは、開発にかかったコストのすべてだ。分析、プログラミング、テストなどのすべての努力が無駄になる。氏が言うには、ニーズを正確に理解していても、推定に基づく機能はふたつの深刻なコストを産む。ひとつは、価値の遅れのコスト、もうひとつは、維持のコストだ。氏は次のように説明する。
遅延のコスト: 利益を生成する他の機能開発に労力を割くことができる。
維持のコスト: 推定に基づく機能は複雑さをソフトウエアに追加する。この複雑さはソフトウエアの変更やデバッグを難しくし、他の機能のコストを上げる。機能追加のコストが上がり、追加の遅延のコストが発生する。プロダクション環境に適用するまでに時間がかかるからだ。
正しい機能を間違った作り方で作ってしまったのを修正するのはさらにコストがかかる、と氏は言う。
開発チームはユーザとコードについて常に学習します。使っているツールについて学習しますが、このようなツールは定期的にアップデートされます。コードについても学習します。このような学習によって、6ヶ月前にコーディングされた機能を今見ると、あるべき方法でコーディングされていないことに気付きます。このような場合は、技術的負債を積み増し、修正のコストや回避のコストを考えなければなりません。
Martin氏が言うには、yagniは大きな機能でも小さな機能にも適用される。小さなyagniを積み重ねることでコードの複雑さは大きく削減できると同時に、必要な機能は素早く提供できるようになる。