4 ms·

That plus a thousand special cases, that are quite often absolutely meaningless to implement in code, but still have to be done. What do I mean by that: I work

That plus a thousand special cases, that are quite often absolutely meaningless to implement in code, but still have to be done. What do I mean by that: I work for big corporations mostly and quite often there is the average case that is about 90%-99% of all incoming work. Then there is a myriad of special cases some of which happen every third year on a blood moon, if an eclipse is happening at the same time and the witches chant in the woods... Instead of managing these unicorn-cases by hand, they have to be implemented in code and lead to bugs and a ton more code to review and maintain. Speaking of maintenance... oh, don't get me started on that one, it's a sore spot!

makeitdouble 3y ago
TBF, the current dev team might right now is aware of the edge case how to deal with it, the poor shmuck three years down the line when blood moon eclipse witch chant happens probably wont. In particular, these edge cases tend to be more complex, require more knowledge and have less margin of errors than the standard errors happening 90% of the time. Leaving them as a gift for the future maintainers is a special kind of dick move.
- OtomotO 3y ago
  > Leaving them as a gift for the future maintainers is a special kind of dick move. by whom exactly? I mean, I agree that it's shitty (I was such a maintainer already), but who is responsible (the whole machinery or a specific role?) and how can we change it? I personally try to add meaningful comments to code that may seem "strange". Like code that if I read it and it was written by someone else I would ask myself "Why so complicated?" - that way I hope to improve the situation a bit for future maintainers.
  - makeitdouble 3y ago
    I was thinking at the team/org level. Edge cases are left out after some discussion on how much impact they have and how they'll have to be handled, so there is a conscious choice to not deal with cases that are rare but will happen and require intervention (cases that can just be ignored or worked around out of the system are a different thing, and unknown/unplanned edge cases are just bugs). If there is specific finger pointing needed IMHO it would land either on the manager or the product owner for miscalculating the impact of that decision. PS: To your point on "weird" code, imagine a code that just asserts for some conditions with a "if these conditions are true call XXXX team for help" message on it. That's how I'm representing an unhandled edge case.
Muromec 3y ago
Don't need the moon and witches even. Some datetimes serialized to epoch time around third week of October and here it comes.
nudgeee 3y ago
If you work at a big enough company, that 1% edge case could affect millions of people, so it is definitely worth the brain cycles to consider.
- dgb23 3y ago
  Doesn't that also mean it scales up the negative consequences just as much? More code = more maintenance, risk, bugs, resource usage etc. Sometimes these things are worth it because the manual process is error prone and perhaps frustrating/stressful (these things can't be measured as easily). But sometimes they are not examined critically at all. How often? How many? How important? Are there simpler solutions? Kind of depends on the receiving end of the questions in my experience. Some people are happy if you push back and keep things simple, others have problems with that. I wonder how much does scale affect these basic principles. I would assume that with scale you already have a lot of problems that push even harder towards not implementing every single thing.
  - nudgeee 3y ago
    Here’s the catch, as you scale up, more and more users could get caught in the edge case. Remember why we build systems — for end users to use. It is our job as engineers/technologists to solve them. This is where trade-offs in engineering and product are important. Is the edge case safety critical or poses a safety risk? If so, it definitely should be considered and handled. Does the edge case block a critical user flow (eg. purchase/checkout step)? If so, it should probably be considered. Does the edge case result in some non-critical piece of UX having the wrong padding in some lesser trodden user flow? Possibly acceptable.

makeitdouble 3y ago

TBF, the current dev team might right now is aware of the edge case how to deal with it, the poor shmuck three years down the line when blood moon eclipse witch chant happens probably wont. In particular, these edge cases tend to be more complex, require more knowledge and have less margin of errors than the standard errors happening 90% of the time. Leaving them as a gift for the future maintainers is a special kind of dick move.

OtomotO 3y ago
> Leaving them as a gift for the future maintainers is a special kind of dick move. by whom exactly? I mean, I agree that it's shitty (I was such a maintainer already), but who is responsible (the whole machinery or a specific role?) and how can we change it? I personally try to add meaningful comments to code that may seem "strange". Like code that if I read it and it was written by someone else I would ask myself "Why so complicated?" - that way I hope to improve the situation a bit for future maintainers.
- makeitdouble 3y ago
  I was thinking at the team/org level. Edge cases are left out after some discussion on how much impact they have and how they'll have to be handled, so there is a conscious choice to not deal with cases that are rare but will happen and require intervention (cases that can just be ignored or worked around out of the system are a different thing, and unknown/unplanned edge cases are just bugs). If there is specific finger pointing needed IMHO it would land either on the manager or the product owner for miscalculating the impact of that decision. PS: To your point on "weird" code, imagine a code that just asserts for some conditions with a "if these conditions are true call XXXX team for help" message on it. That's how I'm representing an unhandled edge case.

Muromec 3y ago

Don't need the moon and witches even. Some datetimes serialized to epoch time around third week of October and here it comes.

nudgeee 3y ago

If you work at a big enough company, that 1% edge case could affect millions of people, so it is definitely worth the brain cycles to consider.

dgb23 3y ago
Doesn't that also mean it scales up the negative consequences just as much? More code = more maintenance, risk, bugs, resource usage etc. Sometimes these things are worth it because the manual process is error prone and perhaps frustrating/stressful (these things can't be measured as easily). But sometimes they are not examined critically at all. How often? How many? How important? Are there simpler solutions? Kind of depends on the receiving end of the questions in my experience. Some people are happy if you push back and keep things simple, others have problems with that. I wonder how much does scale affect these basic principles. I would assume that with scale you already have a lot of problems that push even harder towards not implementing every single thing.
- nudgeee 3y ago
  Here’s the catch, as you scale up, more and more users could get caught in the edge case. Remember why we build systems — for end users to use. It is our job as engineers/technologists to solve them. This is where trade-offs in engineering and product are important. Is the edge case safety critical or poses a safety risk? If so, it definitely should be considered and handled. Does the edge case block a critical user flow (eg. purchase/checkout step)? If so, it should probably be considered. Does the edge case result in some non-critical piece of UX having the wrong padding in some lesser trodden user flow? Possibly acceptable.