3 ms·

Refactoring is a really tough sell for an OKR. We use OKRs and we have had a couple quality initiatives in the past that were tied directly to OKRs and even the

Refactoring is a really tough sell for an OKR. We use OKRs and we have had a couple quality initiatives in the past that were tied directly to OKRs and even then it’s hard to get that work prioritized. At the end of the day as long as users aren’t complaining product is going to index on features and value added. I’ve never been somewhere that would let you make a goal around redoing something that already works (even if it works like shit). I think the reason for that is it’s hard to come up with a key result that can be measured once the work is done — other than “it still works the same”

nickbauman 8y ago
Should not be a tough sell. Refactoring, from an OKR perspective, means you are protecting the ability to ship. Which means that there are tacit implications to OKRs. Nobody would want you to prioritize some rando OKR that would cause code quality to drop to the point that it impacts shipping (because now there are, say, bugs that shut off entire functional areas or something stupid like that). OKRs have built-in assumptions and these tend to be around protecting existential abilities of the company, like shipping code.
titanomachy 8y ago
This is an interesting point. I wonder if it might be easier at larger companies, since you can use metrics like "we are receiving fewer complaints that our system is hard to integrate with or understand". You might improve on some measure of "velocity", but on a small dev team that's so noisy as to be nearly meaningless. I guess you could track employee frustration as a primary target.
james_s_tayler 8y ago
I've been thinking about this lately. Mainly OKRs around developer experience. As an objective that's an easy one to come up with plenty of key results that actually tie in to refactoring, retiring old systems and upgrading existing ones. Currently where I work we have a fixed allocation % of dev/test time for technical improvements. In practice it works really well if you approach it strategically and use it to achieve things over the long term. Things you can just chip away at that steadily improve the health of the code, architecture and product. I find if it's used on a purely operational basis where you just ad-hoc improve stuff you find then it's not super effective, but it's pretty solid when the team is onboard with leveraging it to achieve better and better DX over the long term. Otherwise "refactoring" barely ever gets done and products slowly suffer bit-rot. I think OKRs are a perfect fit for such a scenario. We don't use them, but I kinda use them internally as part of my mental model.

nickbauman 8y ago

Should not be a tough sell. Refactoring, from an OKR perspective, means you are protecting the ability to ship. Which means that there are tacit implications to OKRs. Nobody would want you to prioritize some rando OKR that would cause code quality to drop to the point that it impacts shipping (because now there are, say, bugs that shut off entire functional areas or something stupid like that). OKRs have built-in assumptions and these tend to be around protecting existential abilities of the company, like shipping code.

titanomachy 8y ago

This is an interesting point. I wonder if it might be easier at larger companies, since you can use metrics like "we are receiving fewer complaints that our system is hard to integrate with or understand". You might improve on some measure of "velocity", but on a small dev team that's so noisy as to be nearly meaningless. I guess you could track employee frustration as a primary target.

james_s_tayler 8y ago

I've been thinking about this lately. Mainly OKRs around developer experience. As an objective that's an easy one to come up with plenty of key results that actually tie in to refactoring, retiring old systems and upgrading existing ones. Currently where I work we have a fixed allocation % of dev/test time for technical improvements. In practice it works really well if you approach it strategically and use it to achieve things over the long term. Things you can just chip away at that steadily improve the health of the code, architecture and product. I find if it's used on a purely operational basis where you just ad-hoc improve stuff you find then it's not super effective, but it's pretty solid when the team is onboard with leveraging it to achieve better and better DX over the long term. Otherwise "refactoring" barely ever gets done and products slowly suffer bit-rot. I think OKRs are a perfect fit for such a scenario. We don't use them, but I kinda use them internally as part of my mental model.