J'aime ce passage:
"""
La dette technique est donc un facteur largement négligé dans les décisions quand il n’est pas complètement ignoré. Très souvent dans notre métier, les décisions sont prises avec une vision très court terme, sans trop penser aux conséquences sur le long terme. Or, ce qui est intéressant sur du court terme l’est rarement sur du long terme, et ça s’exprime notamment à travers la dette technique.

Lorsque la pression économique nécessite de s’endetter, le bon sens voudrait que cette dette soit remboursée dès que la période critique est passée. On emploie souvent dans cette situation l’expression « nous le ferons plus tard ». Mais « plus tard » signifie bien souvent « jamais ». Les décideurs ont en effet toujours besoin de choses plus prioritaires (à leurs yeux en tout cas) que de rembourser la dette technique. C’est ainsi que la dette s’accumule, petit à petit.
"""
Oui, la tentation du surendettement est grande.
Faire un truc vite fait mal fait, qui fait le taff mais qui te pétera à la gueule ou qui te ralentira dans ton travail plus tard. C'est comme construire une maison sur des fondations en polystyrene. C'est d'autant plus chaud sur du code d'infrastructure. Car remettre en cause du code qui tourne en production exige de faire des migrations, elles-mêmes dangereuses et chronophages. Le produit c'est avant-tout une infra qui fonctionne et qui est robuste, rien d'autre.

Il faut réussir à avancer relativement rapidement (avec de l'intégration continue) tout en se projetant sur le long terme. Il y a un juste milieu à trouver.

Lien via http://geekandtips.com/links/?kyw5Xg