Construisez-en un pour jeter vs Effet du deuxième système

Question

D'une part, il y a un conseil qui dit "construire un à jeter". Ce n'est qu'après avoir terminé un système logiciel et vu le produit final que nous réalisons ce qui s'est mal passé dans la phase de conception et que nous avons dû comprendre comment nous aurions vraiment dû le faire.

D'un autre côté, il y a "l'effet du deuxième système" qui dit que le deuxième système du même type qui est conçu est généralement pire que le premier; Il existe de nombreuses fonctionnalités qui ne rentraient pas dans le premier projet et ont été poussées dans la deuxième version conduisant généralement à trop complexes et trop conçues.

Ici, n'est-ce pas une contradiction entre ces principes? Quelle est la vue correcte sur les problèmes et où est la frontière entre ces deux?

Je crois que ces «bonnes pratiques» ont d'abord été promues dans le livre fondateur Le mythique-mois-mois par Fred Brooks.

Je sais que certains de ces problèmes sont résolus par des méthodologies agiles, mais au fond, le problème est toujours les principes toujours; Par exemple, nous ne ferions pas d'importants changements de conception 3 sprints avant de passer en direct.