đ ItĂ©rer est toujours une perte de temps et dâargent. Un dĂ©veloppeur omniscient recueillant un besoin parfait travaille de maniĂšre linĂ©aire. Aucune itĂ©ration volontaire ne lui est nĂ©cessaire, car le problĂšme est bien dĂ©fini. Il ne cause pas dâitĂ©rations involontaires car il produit un code simple, exempt de dĂ©fauts, adĂ©quat par rapport au besoin, sans aucune ambiguĂŻtĂ©.
đ§ Si nous quittons le monde des fĂ©es, lâitĂ©ration est bourrĂ©e dâavantages : qualitĂ© en hausse donc baisse des dĂ©fauts, meilleure lisibilitĂ© donc meilleure maintenabilitĂ©, plus faible complexitĂ© donc plus grande productivitĂ©, adoption dâune solution plus adaptĂ©e au problĂšme et plus innovante. Autrement dit, itĂ©rer câest compenser nos limites bien humaines par une mĂ©thode dâamĂ©lioration continue. Nous sommes en nĂ©gociation permanente avec les autres parties prenantes, nous-mĂȘme et surtout la froide logique des machines.
đȘ La seule raison pertinente de ne pas itĂ©rer, câest de gagner du temps Ă court-terme, au dĂ©triment du temps long. Câest ce que lâon appelle la dette technique.
đ Voici les conclusions dâune Ă©quipe pakistano-saoudienne, qui a rĂ©alisĂ© une SLR sur prĂšs de 153 Ă©tudes aprĂšs sĂ©lection qualitative.
SOURCE
Mumtaz, Mamoona & Ahmad, Naveed & Ashraf, M. Usman & Alghamdi, Ahmed & Bahadad, Adel & Almarhabi, Khalid. (2022). Iteration Causes, Impact, and Timing in Software Development Lifecycle: SLR. IEEE Access. 10. 1-1. DOI:10.1109/ACCESS.2022.3182703.
Enzo Sandré
đ Lien public DOIs: 10.1109/ACCESS.2022.3182703