3 ms·

That's a really interesting results. Those are the kind of thought you may have but knowing that it actually worked on a production app that's massively used is

by bsaul 8y ago

That's a really interesting results. Those are the kind of thought you may have but knowing that it actually worked on a production app that's massively used is a really valuable thing. Anyone else had similar experience ?

noir_lord 8y ago
I inherited a hilarious bad(ly written) legacy system. One of the first things I did was turn on every possible "throw on error, die on error, assert" in development (could't do it production as it'd just fall over constantly). The constant crashes in dev meant I rapidly fixed the low hanging fruit (undefined indexes etc) and then slowly as I cleaned an area up I'd leave the asserts in once in production since at that point what I'm asserting is "I think I fixed all the insanity but tell me straight away if my assumption was bad". Painful very painful but those areas now cause me very few if any issues.
pfranz 8y ago
I work in visual effects for film writing internal tools. Usually they're tools that take data from department to department or the department uses internally; fairly short processes that serialize data in between. One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble. As you would expect, when errors did happen it was because of bad data from further up. You really had to know the system well to be productive (the cynical of us thought the developers liked this because they could look like heroes). I prefer to error early and clearly and I got a lot of push back. To be fair to them, often times the errors would be irrelevant to the specific thing they needed and it would have been preferable to ignore and carry on. It felt like I was imposing a bunch of bureaucracy and yak shaving. But bringing on new people and scaling the amount of data going through would have been impossible without more structure.
- WalterBright 8y ago
  I find it sad that there seems to be no conventional wisdom in the software business about the proper way to do this. Everyone starts from scratch and tries to learn it the hard way.

by bsaul 8y ago

noir_lord 8y ago

I inherited a hilarious bad(ly written) legacy system. One of the first things I did was turn on every possible "throw on error, die on error, assert" in development (could't do it production as it'd just fall over constantly). The constant crashes in dev meant I rapidly fixed the low hanging fruit (undefined indexes etc) and then slowly as I cleaned an area up I'd leave the asserts in once in production since at that point what I'm asserting is "I think I fixed all the insanity but tell me straight away if my assumption was bad". Painful very painful but those areas now cause me very few if any issues.

pfranz 8y ago

I work in visual effects for film writing internal tools. Usually they're tools that take data from department to department or the department uses internally; fairly short processes that serialize data in between. One place I worked had a team that was very adamant about not really having much error checking. Not much of any qc process, either. Wait for someone to complain about bad data and respond. Honestly, this worked really well for small, skunkworks type projects that needed to be nimble. As you would expect, when errors did happen it was because of bad data from further up. You really had to know the system well to be productive (the cynical of us thought the developers liked this because they could look like heroes). I prefer to error early and clearly and I got a lot of push back. To be fair to them, often times the errors would be irrelevant to the specific thing they needed and it would have been preferable to ignore and carry on. It felt like I was imposing a bunch of bureaucracy and yak shaving. But bringing on new people and scaling the amount of data going through would have been impossible without more structure.

WalterBright 8y ago
I find it sad that there seems to be no conventional wisdom in the software business about the proper way to do this. Everyone starts from scratch and tries to learn it the hard way.