5 ms·

Bug free code isn't pragmatic at all. For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge c

Bug free code isn't pragmatic at all. For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases. One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200".

indemnity 3y ago
Another almost worst thing is having production environments with significantly different stacks to what you are using locally, with branches in the code to account for this. This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. And it deploys from one of our old crappy Jenkins pipelines that decided 30 minutes ago to start having a failing volume. Should have just used GitHub Actions + Postgres.
- 0xDEAFBEAD 3y ago
  >This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. Did you consider running a second test instance of the DB in the cloud?
  - indemnity 3y ago
    > Did you consider running a second test instance of the DB in the cloud? This is using the test instance :) The issue replicates both on prod (cloud) and test (cloud). But not locally. So a nice 30 minute deployment pipeline run to test if your fix worked, since we are firewalled from direct DB connections from local dev machines, even for test instances.
    - john_the_writer 3y ago
      I've got a 10 min lag. Now i don't feel so bad. SOP though..
- pixl97 3y ago
  >Another almost worst thing is having production environments with significantly different stacks to what you are using locally, Everyone has a test environment, some people also have a seperate production environment :D Database/datasize issues typically are the worst here. Dev/UAT environments are typically considered a cost center and you'll commonly see them with some small amount of ram and compute resources. Which is fine when you're testing 'small data'. But if you have enterprise style clients that have hundreds of gigs/terabytes of data, your dev environment behavior is generally going to be very different. Ran into a case where an enterprise client ran massive db performance problems. We found an unindexed table scan that was killing performance. When doing a post mortem on it, it turns out that 95% of our customers only had around 5 entries in the table. No reason to add an index to that. But this customer had found a neat and interesting workflow that had added thousands of entries to that table.
deleted 3y ago
[deleted]
lelanthran 3y ago
> One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200". Acceptable for webapps. I can't really think of anywhere else that it becomes acceptable to simply say "We had an oopsie. Try again later". Mostly what you want to do is give the user an actionable error message - i.e. "This is what you can do to fix this error". "cd /somedir" gives errors of the form "permission denied" (i.e. change your perms level, or ask the owner of the dir to change its permissions), "not found" (i.e. that dir does not exist, so create it if you need it), "i/o error" (i.e. your disk may be bad, run fsck), "Not a directory" (i.e. specify a directory, not a file), etc ... With most programs written in HLL these days, all I get is something along the lines of "Operation could not be completed", or, worse an exception handler that has absolutely no clue what is needed to fix the error (a real one I got last week: "expected integer, got string". I have no idea where in the 3k lines of input that field actually is, or what it is called). The only good error messages I see are written in programs that don't have exception handlers, so the error is printed out where and when it happens, and the programmer who wrote the code that generated the error is also forced to handle it, and so has all the context to generate a reasonable error message.
wiz21c 3y ago
> For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases. There's a spcetrum between 'all the edge cases' and 'most of the edge cases'. A web app for a blog is not exactly like an automat onboard the JamesWebb telescop...
myme 3y ago
OP here. This is one of the exact things that, in my mind, makes programming hard. It probably wasn't covered in the post, but striking the right balance between "bug free" and "pragmatism" towards accepting lack of functionality and error tolerance, is crucial. Within certain domains like healh-care (my area these days), space travel, military, edge case management play a significant role in the valuation of where to place your effort (although it doesn't exclude the ability to fail fast and hard during development cycles). In other domains exposing users for these hard failures is considered perfectly fine. It depends... It's just one other aspect - when thinking beyond just the code - that makes the decisions and consideration I have to make every day "hard".
benrutter 3y ago
This is so true. I see a lot of bad APIs and returning something like a 200 response + a message body saying something like "Psych! Actually it'd broken" is a surprisingly common anti-pattern. Reminds me of Petet Gabriel's Worse Is Better[0], one of the insights of which is that it's often better to fail for edge cases than try to handle every single one. [0] https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/WorseIsBetter.html
- Izkata 3y ago
  We had to do this in order to show the user a relevant error message because our system is behind apache and it doesn't forward the content body from wsgi for (IIRC) whole classes of error codes.
- PH95VuimJjqBqy 3y ago
  This particular thing is a matter of opinion, there are pro's and con's to each approach. The question is what constitutes an error and should web semantics and application semantics align? should I return a 404 on a missing record, and if I do, how can I differentiate between that and a routing error? My point is that you're confidently stating something where both sides are neither right nor wrong, they simply value different things.
PH95VuimJjqBqy 3y ago
As long as you're fixing and preventing the 500 in the future, this is how you build stable software. it's not possible to predict everything, so instrument, let your software be loud, and listen to it.

indemnity 3y ago

Another almost worst thing is having production environments with significantly different stacks to what you are using locally, with branches in the code to account for this. This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. And it deploys from one of our old crappy Jenkins pipelines that decided 30 minutes ago to start having a failing volume. Should have just used GitHub Actions + Postgres.

0xDEAFBEAD 3y ago
>This message brought to you by a day of commits dealing with edge cases that only manifest in the cloud environment which uses a "strategic" database technology that is impossible to run locally. Did you consider running a second test instance of the DB in the cloud?
- indemnity 3y ago
  > Did you consider running a second test instance of the DB in the cloud? This is using the test instance :) The issue replicates both on prod (cloud) and test (cloud). But not locally. So a nice 30 minute deployment pipeline run to test if your fix worked, since we are firewalled from direct DB connections from local dev machines, even for test instances.
  - john_the_writer 3y ago
    I've got a 10 min lag. Now i don't feel so bad. SOP though..
pixl97 3y ago
>Another almost worst thing is having production environments with significantly different stacks to what you are using locally, Everyone has a test environment, some people also have a seperate production environment :D Database/datasize issues typically are the worst here. Dev/UAT environments are typically considered a cost center and you'll commonly see them with some small amount of ram and compute resources. Which is fine when you're testing 'small data'. But if you have enterprise style clients that have hundreds of gigs/terabytes of data, your dev environment behavior is generally going to be very different. Ran into a case where an enterprise client ran massive db performance problems. We found an unindexed table scan that was killing performance. When doing a post mortem on it, it turns out that 95% of our customers only had around 5 entries in the table. No reason to add an index to that. But this customer had found a neat and interesting workflow that had added thousands of entries to that table.

deleted 3y ago

[deleted]

lelanthran 3y ago

> One thing that I've found myself doing in recent years is to simply let the program blow up and have the end user experience a 500 error. I know this isn't ideal for so many orgs but I've come to the conclusion that the worst thing you can have happen is a feature that breaks but returns a "200". Acceptable for webapps. I can't really think of anywhere else that it becomes acceptable to simply say "We had an oopsie. Try again later". Mostly what you want to do is give the user an actionable error message - i.e. "This is what you can do to fix this error". "cd /somedir" gives errors of the form "permission denied" (i.e. change your perms level, or ask the owner of the dir to change its permissions), "not found" (i.e. that dir does not exist, so create it if you need it), "i/o error" (i.e. your disk may be bad, run fsck), "Not a directory" (i.e. specify a directory, not a file), etc ... With most programs written in HLL these days, all I get is something along the lines of "Operation could not be completed", or, worse an exception handler that has absolutely no clue what is needed to fix the error (a real one I got last week: "expected integer, got string". I have no idea where in the 3k lines of input that field actually is, or what it is called). The only good error messages I see are written in programs that don't have exception handlers, so the error is printed out where and when it happens, and the programmer who wrote the code that generated the error is also forced to handle it, and so has all the context to generate a reasonable error message.

wiz21c 3y ago

> For any system that is reasonably complex; that solves a real world issue, there's simply no way to handle all the edge cases. There's a spcetrum between 'all the edge cases' and 'most of the edge cases'. A web app for a blog is not exactly like an automat onboard the JamesWebb telescop...

myme 3y ago

OP here. This is one of the exact things that, in my mind, makes programming hard. It probably wasn't covered in the post, but striking the right balance between "bug free" and "pragmatism" towards accepting lack of functionality and error tolerance, is crucial. Within certain domains like healh-care (my area these days), space travel, military, edge case management play a significant role in the valuation of where to place your effort (although it doesn't exclude the ability to fail fast and hard during development cycles). In other domains exposing users for these hard failures is considered perfectly fine. It depends... It's just one other aspect - when thinking beyond just the code - that makes the decisions and consideration I have to make every day "hard".

benrutter 3y ago

This is so true. I see a lot of bad APIs and returning something like a 200 response + a message body saying something like "Psych! Actually it'd broken" is a surprisingly common anti-pattern. Reminds me of Petet Gabriel's Worse Is Better[0], one of the insights of which is that it's often better to fail for edge cases than try to handle every single one. [0] https://dreamsongs.com/WorseIsBetter.html https://dreamsongs.com/WorseIsBetter.html

Izkata 3y ago
We had to do this in order to show the user a relevant error message because our system is behind apache and it doesn't forward the content body from wsgi for (IIRC) whole classes of error codes.
PH95VuimJjqBqy 3y ago
This particular thing is a matter of opinion, there are pro's and con's to each approach. The question is what constitutes an error and should web semantics and application semantics align? should I return a 404 on a missing record, and if I do, how can I differentiate between that and a routing error? My point is that you're confidently stating something where both sides are neither right nor wrong, they simply value different things.

PH95VuimJjqBqy 3y ago

As long as you're fixing and preventing the 500 in the future, this is how you build stable software. it's not possible to predict everything, so instrument, let your software be loud, and listen to it.