> 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.
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:
5. Then go through the list of problems and choose the most horrible ones to resolve6. 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.