4 ms·
I wonder if you can formalize this a bit more. Let W(init,DC) be the initial cost (hours/effort) of writing Dirty Code (DC). Let's assume that the code works f
by abnry 4y ago
I wonder if you can formalize this a bit more.
Let W(init,DC) be the initial cost (hours/effort) of writing Dirty Code (DC). Let's assume that the code works for the intended purpose and doesn't have any bugs.
Let W(init,CC) be the initial cost of writing Clean Code (CC). You'd expect it to be related to W(init,DC) by some proportion: W(init,CC) = (1+alpha)*W(init,DC).
Then there is a probability p that you will want to / extend the code.
Let W(ext,DC) be the amount of effort required to extend the code if the initial code is dirty.
Let W(ext, CC) be the amount of effort required to extend the code if the initial code is clean. I'd expect W(ext,CC) = (1-beta)*W(ext,DC).
Then you can compute E[W(total)|CC) vs E[W(total)|DC]. This will define some trade-off curve based on alpha, beta, p, W(ext,DC) and W(init, DC).
Lots of assumptions here, but I wonder if thinking this through will provide any insights. Obviously, if the probability of extending the code is low, then it always makes sense to write dirty code. If the probability of extending the code is high, then you'll want to write clean code.
- bumby 4y agoI 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/...