4 ms·

This is weird to me... The way I learned the trade, and usually worked, is that bug fixing always comes first! You don't work on new features until the old on

This is weird to me... The way I learned the trade, and usually worked, is that bug fixing always comes first! You don't work on new features until the old ones work as they should. This worked well for the teams I was on. Having a (AFAYK) bug free code base is incredibly useful!!

deleted 11mo ago
[deleted]
Celeo 11mo ago
Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.
- BurningFrog 11mo ago
  That's what I hear. I've had some mix of luck and skill in finding these jobs. Working with people you've worked with before helps with knowing what you're in for. I also don't really ask anyone, I just fix any bugs I find. That may not work in all organizations :)
  - zelphirkalt 11mo ago
    micro-managing middle manager: "Are all your other sprint tasks finished?" code reviewing coworker: "This shouldn't be done on this branch!" (OK, at least this is easy to fix by doing it on a separate branch.)
  - ramon156 11mo ago
    I can guarantee you this doesn't work in our team! you didn't make a ticket, so the PM has no idea what you're doing! Yes, a ticket takes 2 seconds. it also puts me off my focus :P but i guess measuring is more important than achieving
- NegativeK 11mo ago
  I've had to inform leadership that stability is a feature, just like anything else, and that you can't just expect it to happen without giving it time. One leader kind of listened. Sort of. I'm pretty sure I was lucky.
  - deaux 11mo ago
    Ask them if they're into pro sports. If so (and most men outside of tech are in some way), they'll probably know the phrase "availability is the best ability".
    - Herring 11mo ago
      Or just look at your car. Heated seats are sexy in the short term, but boring old reliability and predictability win out long term.
  - dijksterhuis 11mo ago
    i got lucky at my last shop. b2b place for like 2x other customer companies. eng manager person (who was also like 3x other managers :/ ) let everything get super broken and unstable. when i took lead of eng it was quite an easy path to making it clear stability was critical. slow everything down and actually do QA. customer became super happy because basically 3x releases went out with minimal bugs/tweaks required. “users don’t want broken changes immediately, they want working changes every so often” was my spiel etc etc. unfortunately it was impossible to convince people about that until they screwed it all up. i still struggle to let things “get bad so they can get good”, but am aware of the lesson today at least. tl;dr sometimes you gotta let people break things so badly that they become open to another way
    - machomaster 11mo ago
      It's interesting how misaligned your effort is. You put effort into writing an unnecessary tldr on a short post, but couldn't be bothered to properly Capitalize your sentences in order to ensure the readability. Weird.
kykat 11mo ago
In the places that I worked, features came before all else, and bugs weren't fixed unless customers complain
jaredsohn 11mo ago
I'd love to see an actual bug-free codebase. People who state the codebase in bug-free probably just lack awareness. Even stating we 'have only x bugs' is likely not true.
- waste_monk 11mo ago
  >I'd love to see an actual bug-free codebase. cat /dev/null .
  - deleted 11mo ago
    [deleted]
  - Sharlin 11mo ago
    A specific individual execution is not a codebase.
- NegativeK 11mo ago
  Top commenter's "AFAYK" acronym is covering that. The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs.
  - supriyo-biswas 11mo ago
    > The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs. This is usually EMs in my experience. At my last job, I remember reading a codebase that was recently written by another developer to implement something in another project, and found a thread safety issue. When I brought this up and how we’ll push this fix as part of the next release, he went on a little tirade about how proper processes weren’t being followed, etc. although it was a mistake anyone could have made.
- rurban 11mo ago
  We kinda always leave documentation and test bugs in. Documentation teams have different scheduling, and tests are nice TODO's. There are also always bugs detected after shipping (usually in beta), which need to be accounted for.
ben0x539 11mo ago
In your experience, is there a lot of contention over whether a given issue counts as a bug fix or a feature/improvement? In the article, some of the examples were saving people a few clicks in a frequent process, or updating documentation. Naively, I expect that in an environment where bug fixes get infinite priority, those wouldn't count as bugs, so they would potentially stick around forever too.
- BurningFrog 11mo ago
  In my world, improving the UI to save clicks is a new feature, not a bug fix. Assuming it works as intended.
thundergolfer 11mo ago
This is the 'Zero Defects'[1] mode of development. A Microsoft department adopted it in 1989 after their product quality dropped. (Balmer is cc'd on the memo.) 1. https://sriramk.com/memos/zerodef.pdf https://sriramk.com/memos/zerodef.pdf
- waste_monk 11mo ago
  As opposed to the current 100% defects approach they seem to have adopted.
  - tonyedgecombe 11mo ago
    Balmer is no longer there :)
RHSeeger 11mo ago
Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.
- deleted 11mo ago
  [deleted]
- tonyedgecombe 11mo ago
  >For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it. I've seen that very argument several times, it was even in the requirements on one occasion. In each instance it was incorrect, there were times when a second page was reached.
- AdamN 11mo ago
  IMHO the best way to deal with that situation is to mark the bug as wontfix. Better to have a policy of always fixing bugs but be more flexible on what counts as a bug (and making sure the list of them is very small and being actively worked on).
  - RHSeeger 11mo ago
    But it's not "wont fix", because it will get fixed when there's nothing of a higher priority. And it's priority could change at some point. > Better to have a policy of always fixing bugs but be more flexible on what counts as a bug I just disagree with this. It's entirely possible for something to not work correctly, but that fact be unimportant at the moment (or less important than something else).
    - wavemode 11mo ago
      The philosophy of fixing bugs first before implementing new features is not that the bugs you're fixing must be more "important" than the new features. In fact, that's exactly the mindset that "bugs first" is designed to prevent. If you have a mindset where a bug has to be more important than a feature in order to get prioritized, then you will breed a culture in which bugs are rarely prioritized, if ever. (Especially if fixing them would be time-consuming.) This is for the simple reason that, in isolation, any individual feature can almost always be argued to be more important than any individual bug which could've been worked on instead. Yet, in the aggregate, once you've dumped 50 individual low-priority bugs into the backlog, they all add up to a horrendous experience for the user. It's sort of like running a restaurant. Cooking food is how we make money, but you still have to clean the floors. If you keep putting it off to get the food out faster, eventually you're going to be knee-deep in shit.
jaredklewis 11mo ago
Where have you worked where this was practiced if you don’t mind sharing? I’ve seen very close to bug free backends (more early on in development). But every frontend code base ever just always seems to have a long list of low impact bugs. Weird devices, a11y things, unanticipated screen widths, weird iOS safari quirks and so on. Also I feel like if this was official policy, many managers would then just start classifying whatever they wanted done as a bug (and the line can be somewhat blurry anyway). So curious if that was an issue that needed dealing with.
- mavamaarten 11mo ago
  I'm not going to share my employer, but this is exactly how we operate. Bugs first, they show up on the Jira board at the top of the list. If managers would abuse that (they don't), we'd just convert them to stories, lol. I do agree that it's rare, this is my first workplace where they actually work like that.
- zelphirkalt 11mo ago
  Frontend bugs mostly stem from usage of overblown frontend frameworks, that try to abstract from the basics of the web too much. When relying on browser defaults and web standards, proper semantic HTML and sane CSS usage, the scope of things that can go wrong is limited.
  - Sharlin 11mo ago
    It's pretty wild that this is the case now (if it indeed is), given that for a long, long time, sticking to sane, standard stuff was the exact way you'd land in a glitch/compatibility hell. Yes, thanks mostly to IE, but still.
  - DanielHB 11mo ago
    In my experience frontend bugs are usually from over-complicated business logic with layout-issues a distant second.
    - zelphirkalt 11mo ago
brulard 11mo ago
Many of the bugs have very low severity or appear to small minority of users under very specific conditions. Fixing these first might be quite bad use of your capacities. Like misaligned UI elements, etc. Critical bugs should be done immediately of course as a hotfix.
mobeigi 11mo ago
Any modern system with a sizeable userbase has thousands of bugs. Not all bugs are severe, some might be inconveniences at best affecting only a small % of customers. You have to usually balance feature work and bug fixes and leadership almost always favours new features if the bugs aren't critical to address.
Cthulhu_ 11mo ago
Thing is, if you follow a process like scrum, your product owner will set priorities; if there's a bug that isn't critical, it may go down the list of priorities compared to other issues. And there's other bugs that don't really have any measurable impact, or only affect a small percentage of people, etc.

deleted 11mo ago

[deleted]

Celeo 11mo ago

Depending on the size of the team/org/company, working on anything other than the next feature is a hard sell to PM/PO/PgM/management.

BurningFrog 11mo ago
That's what I hear. I've had some mix of luck and skill in finding these jobs. Working with people you've worked with before helps with knowing what you're in for. I also don't really ask anyone, I just fix any bugs I find. That may not work in all organizations :)
- zelphirkalt 11mo ago
  micro-managing middle manager: "Are all your other sprint tasks finished?" code reviewing coworker: "This shouldn't be done on this branch!" (OK, at least this is easy to fix by doing it on a separate branch.)
- ramon156 11mo ago
  I can guarantee you this doesn't work in our team! you didn't make a ticket, so the PM has no idea what you're doing! Yes, a ticket takes 2 seconds. it also puts me off my focus :P but i guess measuring is more important than achieving
NegativeK 11mo ago
I've had to inform leadership that stability is a feature, just like anything else, and that you can't just expect it to happen without giving it time. One leader kind of listened. Sort of. I'm pretty sure I was lucky.
- deaux 11mo ago
  Ask them if they're into pro sports. If so (and most men outside of tech are in some way), they'll probably know the phrase "availability is the best ability".
  - Herring 11mo ago
    Or just look at your car. Heated seats are sexy in the short term, but boring old reliability and predictability win out long term.
- dijksterhuis 11mo ago
  i got lucky at my last shop. b2b place for like 2x other customer companies. eng manager person (who was also like 3x other managers :/ ) let everything get super broken and unstable. when i took lead of eng it was quite an easy path to making it clear stability was critical. slow everything down and actually do QA. customer became super happy because basically 3x releases went out with minimal bugs/tweaks required. “users don’t want broken changes immediately, they want working changes every so often” was my spiel etc etc. unfortunately it was impossible to convince people about that until they screwed it all up. i still struggle to let things “get bad so they can get good”, but am aware of the lesson today at least. tl;dr sometimes you gotta let people break things so badly that they become open to another way
  - machomaster 11mo ago
    It's interesting how misaligned your effort is. You put effort into writing an unnecessary tldr on a short post, but couldn't be bothered to properly Capitalize your sentences in order to ensure the readability. Weird.

kykat 11mo ago

In the places that I worked, features came before all else, and bugs weren't fixed unless customers complain

jaredsohn 11mo ago

I'd love to see an actual bug-free codebase. People who state the codebase in bug-free probably just lack awareness. Even stating we 'have only x bugs' is likely not true.

waste_monk 11mo ago
>I'd love to see an actual bug-free codebase. cat /dev/null .
- deleted 11mo ago
  [deleted]
- Sharlin 11mo ago
  A specific individual execution is not a codebase.
NegativeK 11mo ago
Top commenter's "AFAYK" acronym is covering that. The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs.
- supriyo-biswas 11mo ago
  > The type that claims they're going to achieve zero known and unknown bugs is also going to be the type to get mad at people for finding bugs. This is usually EMs in my experience. At my last job, I remember reading a codebase that was recently written by another developer to implement something in another project, and found a thread safety issue. When I brought this up and how we’ll push this fix as part of the next release, he went on a little tirade about how proper processes weren’t being followed, etc. although it was a mistake anyone could have made.
rurban 11mo ago
We kinda always leave documentation and test bugs in. Documentation teams have different scheduling, and tests are nice TODO's. There are also always bugs detected after shipping (usually in beta), which need to be accounted for.

ben0x539 11mo ago

In your experience, is there a lot of contention over whether a given issue counts as a bug fix or a feature/improvement? In the article, some of the examples were saving people a few clicks in a frequent process, or updating documentation. Naively, I expect that in an environment where bug fixes get infinite priority, those wouldn't count as bugs, so they would potentially stick around forever too.

BurningFrog 11mo ago
In my world, improving the UI to save clicks is a new feature, not a bug fix. Assuming it works as intended.

thundergolfer 11mo ago

This is the 'Zero Defects'[1] mode of development. A Microsoft department adopted it in 1989 after their product quality dropped. (Balmer is cc'd on the memo.) 1. https://sriramk.com/memos/zerodef.pdf https://sriramk.com/memos/zerodef.pdf

waste_monk 11mo ago
As opposed to the current 100% defects approach they seem to have adopted.
- tonyedgecombe 11mo ago
  Balmer is no longer there :)

RHSeeger 11mo ago

Bugs have priorities associated with them, too. It's reasonable for a new feature to be more important than fixing a lower priority bug. For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it.

deleted 11mo ago
[deleted]
tonyedgecombe 11mo ago
>For example, if reading the second "page" of results for an API isn't working correctly; but nobody is actually using that functionality; then it might not be that important to fix it. I've seen that very argument several times, it was even in the requirements on one occasion. In each instance it was incorrect, there were times when a second page was reached.
AdamN 11mo ago
IMHO the best way to deal with that situation is to mark the bug as wontfix. Better to have a policy of always fixing bugs but be more flexible on what counts as a bug (and making sure the list of them is very small and being actively worked on).
- RHSeeger 11mo ago
  But it's not "wont fix", because it will get fixed when there's nothing of a higher priority. And it's priority could change at some point. > Better to have a policy of always fixing bugs but be more flexible on what counts as a bug I just disagree with this. It's entirely possible for something to not work correctly, but that fact be unimportant at the moment (or less important than something else).
  - wavemode 11mo ago
    The philosophy of fixing bugs first before implementing new features is not that the bugs you're fixing must be more "important" than the new features. In fact, that's exactly the mindset that "bugs first" is designed to prevent. If you have a mindset where a bug has to be more important than a feature in order to get prioritized, then you will breed a culture in which bugs are rarely prioritized, if ever. (Especially if fixing them would be time-consuming.) This is for the simple reason that, in isolation, any individual feature can almost always be argued to be more important than any individual bug which could've been worked on instead. Yet, in the aggregate, once you've dumped 50 individual low-priority bugs into the backlog, they all add up to a horrendous experience for the user. It's sort of like running a restaurant. Cooking food is how we make money, but you still have to clean the floors. If you keep putting it off to get the food out faster, eventually you're going to be knee-deep in shit.

jaredklewis 11mo ago

Where have you worked where this was practiced if you don’t mind sharing? I’ve seen very close to bug free backends (more early on in development). But every frontend code base ever just always seems to have a long list of low impact bugs. Weird devices, a11y things, unanticipated screen widths, weird iOS safari quirks and so on. Also I feel like if this was official policy, many managers would then just start classifying whatever they wanted done as a bug (and the line can be somewhat blurry anyway). So curious if that was an issue that needed dealing with.

mavamaarten 11mo ago
I'm not going to share my employer, but this is exactly how we operate. Bugs first, they show up on the Jira board at the top of the list. If managers would abuse that (they don't), we'd just convert them to stories, lol. I do agree that it's rare, this is my first workplace where they actually work like that.
zelphirkalt 11mo ago
Frontend bugs mostly stem from usage of overblown frontend frameworks, that try to abstract from the basics of the web too much. When relying on browser defaults and web standards, proper semantic HTML and sane CSS usage, the scope of things that can go wrong is limited.
- Sharlin 11mo ago
  It's pretty wild that this is the case now (if it indeed is), given that for a long, long time, sticking to sane, standard stuff was the exact way you'd land in a glitch/compatibility hell. Yes, thanks mostly to IE, but still.
- DanielHB 11mo ago
  In my experience frontend bugs are usually from over-complicated business logic with layout-issues a distant second.
  - zelphirkalt 11mo ago

brulard 11mo ago

Many of the bugs have very low severity or appear to small minority of users under very specific conditions. Fixing these first might be quite bad use of your capacities. Like misaligned UI elements, etc. Critical bugs should be done immediately of course as a hotfix.

mobeigi 11mo ago

Any modern system with a sizeable userbase has thousands of bugs. Not all bugs are severe, some might be inconveniences at best affecting only a small % of customers. You have to usually balance feature work and bug fixes and leadership almost always favours new features if the bugs aren't critical to address.

Cthulhu_ 11mo ago

Thing is, if you follow a process like scrum, your product owner will set priorities; if there's a bug that isn't critical, it may go down the list of priorities compared to other issues. And there's other bugs that don't really have any measurable impact, or only affect a small percentage of people, etc.