3 ms·

While this is a good goal, and I don't think it's not a sensible goal, the amount of developer bandwidth required to take the approach given in the article is e

by Linell 11y ago

While this is a good goal, and I don't think it's not a sensible goal, the amount of developer bandwidth required to take the approach given in the article is enormous. Fixing exceptions as they come in is great if you've got someone on deck specifically for fixing them, but what happens if everyone is already working on something else? Especially if that exception is something that is relatively unimportant? The idea of setting aside time for working on it is much better. I like to do a refactor Friday and work specifically on this type of goal.

lostcolony 11y ago
I've been in environments where it worked just fine. Bug fixes (and exceptions = bug fix) always took priority over features. And yet not only did we never get delayed, we routinely were ahead of schedule. As the article points out, the trick is to get it into your blood -at the start-. If it feels like fixing exceptions takes all your time it's probably because you have let a lot of them creep in. How many known exceptions do you introduce per sprint? It should be zero; nothing new that you're writing should be creating an exception, that isn't fixed in the sprint. So what's left? Exceptions that are uncovered outside of the sprint. That is, you had a feature written, tests for it written, QA test it, client demos show it off, and any exception you saw you fixed already. So outside of all of that, where can exceptions even occur? Well, after release, obviously. Weird race conditions, deviations off the critical path, users doing unexpected things, etc. But the frequency of those should be pretty low. Maybe one, two a sprint, max? Surely you can take the time to dig in and fix those without causing the sprint to slip. Now, as the article also mentions, when you start getting a huge, complex codebase (either due to time, or team size), this gets harder. More complexity = more edge cases. That's one of the reasons to reduce complexity wherever possible, to isolate functionality as much as possible. And this also assumes you have a development process that has you delivering every sprint, and having the stuff used. If you're doing some waterfall "we'll code like crazy for the next year, then test, then deliver", yeah, you probably can't do it. You already said the feature was done; no time to fix that bug! Sorry.

by Linell 11y ago

lostcolony 11y ago

I've been in environments where it worked just fine. Bug fixes (and exceptions = bug fix) always took priority over features. And yet not only did we never get delayed, we routinely were ahead of schedule. As the article points out, the trick is to get it into your blood -at the start-. If it feels like fixing exceptions takes all your time it's probably because you have let a lot of them creep in. How many known exceptions do you introduce per sprint? It should be zero; nothing new that you're writing should be creating an exception, that isn't fixed in the sprint. So what's left? Exceptions that are uncovered outside of the sprint. That is, you had a feature written, tests for it written, QA test it, client demos show it off, and any exception you saw you fixed already. So outside of all of that, where can exceptions even occur? Well, after release, obviously. Weird race conditions, deviations off the critical path, users doing unexpected things, etc. But the frequency of those should be pretty low. Maybe one, two a sprint, max? Surely you can take the time to dig in and fix those without causing the sprint to slip. Now, as the article also mentions, when you start getting a huge, complex codebase (either due to time, or team size), this gets harder. More complexity = more edge cases. That's one of the reasons to reduce complexity wherever possible, to isolate functionality as much as possible. And this also assumes you have a development process that has you delivering every sprint, and having the stuff used. If you're doing some waterfall "we'll code like crazy for the next year, then test, then deliver", yeah, you probably can't do it. You already said the feature was done; no time to fix that bug! Sorry.