Никогда ничего не делайте, пока не будете готовы использовать это, в том числе и в программном обеспечении? [Принцип Toyota]

Думать именно так - хорошая гибкая практика. Существует также что-то, называемое Test-Driven-Development, которое помогает вам получать программное обеспечение без ошибок (почти), но также имеет тот побочный эффект, что НИЧЕГО не реализовано, что вы не используете.

Примером является ваш собственный класс коллекции. Если вам нужны только метод Add и метод ToArray, тогда зачем тратить время на реализацию методов Remove и Count?

Так что да. Следуйте этому принципу :)

Вроде да. Это основная часть гибкая философия.

По сути, предпочтение отдается гибкости и скорости реакции по сравнению с большим дизайном и громоздкими техническими характеристиками. Один из лучших способов сделать это - построить столько, чтобы удовлетворить ваши текущие требования, потому что вы никогда не знаете, когда они изменятся.

Это немного старая новость. Его часто называют «Тебе это не понадобится» («You Arent 'Going to Need It» на неидоматическом английском) и сокращенно ЯГНИ.

Проблемы, связанные с реализацией функции, когда она вам не нужна:

• реализация отнимает время от разработки необходимых функций
• эту функцию сложно задокументировать и протестировать, поскольку, если она вам не нужна, кто знает, что именно она должна делать?
• поддержка функции займет дополнительное время
• функция добавляет дополнительный код, усложняя кодовую базу
• эта функция может иметь эффект снежного кома, в результате чего она предлагает другие функции, которые вы затем можете добавить, даже если они не нужны

Это май применимо к созданию программного обеспечения, но я не уверен, что применимо делает

Если мы рассмотрим пять элементов в «Toyota-способ принятия решений», исходя из принципа, что «то, как вы приходите к решению, так же важно, как и качество решения»:

[режим юмора ВКЛ]

• Выяснение того, что происходит на самом деле, включая генчи гембуцу.

  Except that sometime, one does finally understand what is going on when the client explain to us at the end of the project;)

• Понимание основных причин, которые объясняют внешний вид поверхности - вопрос «Почему?» в пять раз.

  Sure but the client is not available enough during the project ;)

• Широкое рассмотрение альтернативных решений и разработка подробного обоснования предпочтительного решения.

  Too late, the programmers are already coding like madmen :)

• Достижение консенсуса внутри команды, включая сотрудников Toyota и внешних партнеров.

  Oops that programmer is already re-writing the authentification system even though the old one was working fine

• Использование очень эффективных средств связи, чтобы сделать с первого по четвертый, предпочтительно с одной стороны одного листа бумаги.

  Did you hear "death by powerpoint" ? This is not always our strong suit ;)

[режим юмора ВЫКЛ]

Серьезно, как было сказано в предыдущих ответах, философия Agile действительно касается некоторых основных пользователей этого принципа Toyota.

И может быть немного богаче, чем просто "Тебе это не понадобится", как описано в книге "Путь Toyota"