bglusman
commented
10 years ago @SeanMarcia yeah, I'd like to have ways to visualize the debt over time... I don't know if equating 'points' of tech debt to dollars should be default/built into the software, but it's certainly a reasonable way to try and construct the customized points we output, as some kind of approximation of cost. I think making that too explicit could be kind of dangerous, I think of it a little more like story points in an agile sprint, as being more about uncertainty and velocity/drag than about dollars and cents.
Have you had a chance to play any yet? I've been trying to contribute to volt also, and had my attention divided as I'm pretty excited about volt, but also want to get debt_ceiling towards a viable v1.
csexton
I missed dcamp so you may have nixxed this idea.
In addition to a Debt Ceiling, I really like the idea of having a "Technical Debt Clock" ie- http://www.usdebtclock.org/ ideally something with a graph/change variable. So you'd see something like: Current Technical Debt: $52000 Change: Last week: +$5600, Last month: +$11000
I see a debt clock as a valuable tool to show business people in organizations. This would require setting arbitrary numbers (which could be altered) to different variables. So, for example, lets say that for simplicity we are valuing an hour of developer time at $100 (wage, benefits, taxes, etc). We can then make the assumption that each #FIXME in the code is $1000 worth of technical debt since we assume that you make a #Fixme comment when you know it is going to be more than a days work (in this case 10 hours.) Similarly a #Todo may be $1500, #Optimize $600, #Hack $2000, #Dirty-dirty-horrible-hack-and-I'm-sorry-to-whoever-has-to-fix-this: $4000, etc. Again all the numbers should be editable. This way devs can say something like "You know how we've been rushing to get get all these fixes and features deployed? Well because we've been under the gun pushing out those features in 3 days we've done some stuff that isn't best practice and we're incurring technical debt, from our code metrics tool you can see that we've jumped up $9500 worth of debt." Or something like that.
I wonder if we should fail the tests when the ceiling has been breached or if we should just put in warning messages/notifications? If a code base is at/over the ceiling and a manager is telling their devs that to code some features, before fixing/refactoring I imagine they'll just remove the gem if they can't run their tests.
I love the idea of using rubycritic as a starting point and I'm going to update the documentation to reflect that users should use real dollar amounts to for each of the ruby critic grades. Like what I was talking about above, if they feel a grade of b on a line is going to cost 1 developer hour they should put in 100, and so forth.
I do love this idea and am excited about it. Once I give rubycritic a read I feel I'll be in a good place to contribute. Everything I've said here are just ideas for discussion with the caveat that I wasn't at dcamp so if you guys talked about any of this stuff let me know!