Timeline for Fail fast is brittle
Current License: CC BY-SA 4.0
21 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Jul 15 at 16:21 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 12 characters in body
|
| Jul 15 at 16:19 | comment | added | greenoldman | @DocBrown thank you for clarification. With such perspective I have no questions/doubts :-). | |
| Jul 15 at 14:14 | comment | added | Doc Brown | @greenoldman: ok, I reworded my answer a little bit, maybe it is clearer now. Just search this site about "Fail fast", you will surely find lots of Q&As which associate this principle with bugs in code. | |
| Jul 15 at 14:12 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 218 characters in body
|
| Jul 15 at 13:57 | comment | added | greenoldman | @DocBrown, I simply expressed my surprise, this is the first time I saw someone ties bugs in code (i.e. handling them) with fail fast. If you could expand it a little, or give some reference it would be helpful. Thank you in advance. | |
| Jul 15 at 13:55 | comment | added | greenoldman | @Basilevs in this context of course this is understandable, but Doc Brown explicitly wrote "in code". Code means implementation. | |
| Jul 15 at 13:32 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 36 characters in body
|
| Jul 15 at 13:24 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 4 characters in body
|
| Jul 15 at 12:49 | comment | added | Doc Brown | @greenoldman: "Honestly I first read that fail fast is for handling bugs" - yes, that's what I wrote. Not sure what you are trying to tell me. | |
| Jul 15 at 12:39 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 106 characters in body
|
| Jul 15 at 10:26 | comment | added | Basilevs | @greenoldman in this context FF protects you from specification "bugs". If specification is ill-defined, parser failures will help discovering this. | |
| Jul 15 at 5:46 | comment | added | greenoldman | Honestly I first read that fail fast is for handling bugs. AFAIK is general principle that is better to detect problem quickly to avoid costly handling it later -- it applies to introducing products to the market, and handling data. Avoiding bugs -- yes, because FF helps in keeping code smaller (smaller codebase = less bugs), but assuming you have bugs... I don't see direct connection. | |
| Jul 13 at 17:28 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 22 characters in body
|
| Jul 13 at 16:32 | comment | added | J_H | rfc-editor.org/rfc/rfc9413 | |
| Jul 13 at 15:26 | comment | added | Basilevs | Unfortunately, we can't relax validation rules in public interface, so we have to reject even small discrepancies. The reason is simple - relaxed requirements is a feature(even if it is not documented), users rely on features. Removal of such feature is backward incompatible. Making irreversible changes like that should be done only when all other options are exhausted. Initial version of your program HAS TO contain the strictest validation possible, relax it only after user feedback and careful consideration. | |
| Jul 13 at 11:14 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 155 characters in body
|
| Jul 13 at 11:08 | history | edited | Doc Brown | CC BY-SA 4.0 |
added 155 characters in body
|
| Jul 13 at 10:40 | comment | added | NimChimpsky | ietf.org/archive/id/draft-iab-protocol-maintenance-05.html | |
| Jul 13 at 5:45 | history | edited | Doc Brown | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Jul 13 at 5:35 | history | edited | Doc Brown | CC BY-SA 4.0 |
deleted 2 characters in body
|
| Jul 13 at 5:28 | history | answered | Doc Brown | CC BY-SA 4.0 |