3 ms·

There are a few side-affects of technical debt that drive me nuts. These come from companies where developers are autonomous, self-choosing of time investment:

There are a few side-affects of technical debt that drive me nuts. These come from companies where developers are autonomous, self-choosing of time investment: * continuous complaint without action (i.e. pretending to be a victim of the system you’ve built) * lack of measurements for a system (technical debt or not, how is it working? Are you improving your measurement system after each failure to further understand the system?) * unbuilt is better than unmaintained (this builds off the previous two — tell me what we learned from our previous attempts. If you didn’t understand the quality of the previous attempt, then how do we know if we actually improved?) I’m down with fixing technical debt, just show me some metrics that prove that it was an improvement.

waterlink 8y ago
> pretending to be a victim of the system you’ve built Nicely put! I haven’t thought of it this way. > Are you improving your measurement system after each failure to further understand the system? Oh my god. Yes. This is a quote that made my day. So far, it feels like we need to: 1. Have a concept of area (and maybe sub-area) of the code-base 2. Do frequent checks how painful it is to work with a certain area. Maybe, after every feature (ticket, what have you), make developers record how they felt about the areas that they’ve touched, and why. For example, this was really painful because this class is just too coupled to this other one or something like that. Track this information. 3. Track frequency and size of changes required to different areas in the code right now (+ anticipation in the next period, whatever it is). 4. Regularly have a technical retro, where you look at the areas, and prioritize areas that: * give the most pain AND * need to be frequently changed now and in the future 5. Then go through the list of problems and choose the most horrible ones to resolve 6. Schedule time to resolve these, just like we do with features/tickets/what have you. This is just a draft of what comes to my mind.
- invertednz 8y ago
  This is very similar to what my startup is looking to help with.

waterlink 8y ago

> pretending to be a victim of the system you’ve built Nicely put! I haven’t thought of it this way. > Are you improving your measurement system after each failure to further understand the system? Oh my god. Yes. This is a quote that made my day. So far, it feels like we need to: 1. Have a concept of area (and maybe sub-area) of the code-base 2. Do frequent checks how painful it is to work with a certain area. Maybe, after every feature (ticket, what have you), make developers record how they felt about the areas that they’ve touched, and why. For example, this was really painful because this class is just too coupled to this other one or something like that. Track this information. 3. Track frequency and size of changes required to different areas in the code right now (+ anticipation in the next period, whatever it is). 4. Regularly have a technical retro, where you look at the areas, and prioritize areas that: * give the most pain AND * need to be frequently changed now and in the future 5. Then go through the list of problems and choose the most horrible ones to resolve 6. Schedule time to resolve these, just like we do with features/tickets/what have you. This is just a draft of what comes to my mind.

invertednz 8y ago
This is very similar to what my startup is looking to help with.