# Dette technique et TTM
# Dette technique (Technical Debt)
"Les ruptures technologiques doivent se faire dans la continuité."
Idée générale est d'ignorer la dette sur le code legacy qui n'a pas besoin d'évoluer et de se focus uniquement sur le delta entre les versions pour que le nouveau soit nickel. Il faut être très rigoureux sur la qualité du nouveau code (ex : test coverage 80%+)
# image du tapis roulant
La dette technique appliquée au développement logiciel, en particulier en web, c'est à peu près comme avancer sur un tapis roulant en sens inverse. Au début ce tapis roulant fonctionne très lentement. Il faut affecter une partie de son énergie pour s'assurer que le tapis continue de tourner lentement en effaçant la dette. Si on ne le fait pas, on va peut être avancer plus vite au début, mais plus le tapis ira vite plus on ralentira, et on finira par faire du sur-place puis par tomber.
# rotten software
Synonymes : Software rot, also known as code rot, software erosion, software decay or software entropy.
Cf Software rot - en.wikipedia.org
Attention Revoir la définition ci-dessus (surtout le tapis roulant) au regard de la perception de Arnaud Lemaire basée sur la définition de Ward Cuningham :
La dette est un choix à ne pas confondre avec le "rotten software".
Dans quelle catégorie faire entrer l'évolution technique ?
# Time To Market
Egalement nommé Time To Deliver (TTD)
# Relation TD & TTM
# speed vs quality
# risques et difficultés projets
Cf projet SIRHEN (www.zdnet.fr, dev.com)
- quand la techno choisie évolue très vite (typiquement tout ce qui est web based) : risque que la dette s'accumule plus vite que la capacité à la résorber jusqu'à aboutir en quelques années à une obsolescence totale conduisant à un nouveau risque : Difficulté à trouver des techniciens sur la techno obsolète.
- confier la rédaction des EDB et specs à du personnel connaissant le métier mais n'ayant aucune compétence de rédaction de specs.
- quand le domaine métier évolue tout le temps avec des méthodos de gestion de projet provoquant des effets tunnels
- sur un domaine métier déjà informatisé qui évolue peu pendant une longue période, le personnel se repose sur le SI existant et oublie peu à peu le métier (du fait de l'habitude et du fait du turnover), lorsqu'il faut refondre l'appli plus personne ne connait complètement le métier
- implémentation du métier dans une techno propriétaire non standard
- implémentation du métier mélangée aux considérations techniques (I/O, BDD, fichiers, etc ...), cf Clean Architecture
# stats and reports
Chaos Report - www.standishgroup.com - 1994
For 1994, USA spend 250b$ per year on IT application dev on around 175K projects.
Average cost per project :
- large company is 2.322m$
- medium company is 1.331m$
- small company is 0.434m$
Sample result for 1994 : T1 = 16.2%, T2 = 52.7%, T3 = 31.1%
- project resolution type 1 (project success) : The project is completed on-time, on-budget, with all features and functions as initially specied
- project resolution type 2 (project challenged) : The project is completed and operationnal but over-budget, over the time estimate, and offers fewer features and functions than originally specified
- project resolution type 3 (project impaired) : The project is canceled at some point during the development cycle
| Year | Successful (%) | Challenged (%) | Failed (%) |
|---|---|---|---|
| 1994 | 16 | 53 | 31 |
| 1996 | 27 | 33 | 40 |
| 1998 | 26 | 46 | 28 |
| 2000 | 28 | 49 | 23 |
| 2004 | 29 | 53 | 18 |
| 2006 | 35 | 46 | 19 |
| 2009 | 32 | 44 | 24 |
Conclusions contested by The rise and fall of the chaos report figures - IEEE Software - 2010.
# Triangle
QUALITE
^
/ \
/ \
/ \
/ \
/ PROJET \
/ \
COUT /_____________\ DELAI
Utiliser le triangle :
- Rapide et pas cher : Mauvaise qualité
- Rapide et de bonne qualité : Cher
- Bonne qualité et pas cher : Lent
Ce qu’il faut éviter (ou qui n'existe pas) :
- Rapide, de bonne qualité et pas cher
- Lent, de mauvaise qualité, et cher
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
SCOPE
^
/ \
/ \
/ \
/ \
/ QUALITY \
/ \
COST /_____________\ TIME
1. The quality of work is constrained by the project's budget, deadlines and scope (features).
2. The project manager can trade between constraints.
3. Changes in one constraint necessitate changes in others to compensate or quality will suffer.
For example, a project can be completed faster by increasing budget or cutting scope. Similarly, increasing scope may require equivalent increases in budget and schedule. Cutting budget without adjusting schedule or scope will lead to lower quality.
In practice, however, trading between constraints is not always possible. For example, throwing money (and people) at a fully staffed project can slow it down. Moreover, in poorly run projects it is often impossible to improve budget, schedule or scope without adversely affecting quality.
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# services
Greenkeeper sits between npm and GitHub, observing all of the modules you depend on. When they get updated, your project gets a new branch with that update. Your CI tests kick in, and we watch them to see whether they pass.
Based on the test results and your current version definitions we will open up clear, actionable issues for you. If there’s nothing for you to do, we won’t nag you.
Let the friendly Greenkeeper bot take all the dull work of keeping your dependencies up to date off your shoulders and, optimally, boil it all down to a few clicks. This is as close to fully automatic as we could possibly make it.