3 ms·
I would also include a probability of an bug being introduced while extending the code. Code quality tends to be harder to track as the number of system interfa
by bumby 4y ago
I would also include a probability of an bug being introduced while extending the code. Code quality tends to be harder to track as the number of system interfaces expands. Particularly when it coordinates efforts between physical systems, even "clean code" can cause coordination failures because the context has changed by the extension. The example my mind always goes to is the Ariane V failure; it was a failure of 'clean code' in new context.[1]
Then there is the severity of the potential failure. So the additional risk should also encompass both the probability of failure when extending code and the severity of that failure.
[1]http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html http://sunnyday.mit.edu/accidents/Ariane5accidentreport.html
- geocar 4y ago> I would also include a probability of an bug being introduced while extending the code. The number of sprints you spend changing a bit of code might also be a metric worth tracking as well: https://www.microsoft.com/en-us/research/wp-content/uploads/2016/02/bursts.pdf https://www.microsoft.com/en-us/research/wp-content/uploads/...