3 ms·

Not the op but I take it to mean avoid concrete concepts in code around those edge cases. For example in OO avoid making a derived class for a French tax calcu

Not the op but I take it to mean avoid concrete concepts in code around those edge cases. For example in OO avoid making a derived class for a French tax calculation for your one French customer’s invoice. I’m assuming here that your product is not an accounting package and the tax issue is just for SaaS billing. Instead make the design loose enough that this can be accommodated by data. Maybe even manually enter their tax amount in a free text field. But tying up the code for that edge case (and doing so for every edge case) will lead to a complicated system.

macando 7y ago
Pretty much this. It's especially true in startups where new features and edge cases pile up really fast. Solve a new edge case manually in the beginning (like adding a simple field instead of a smart calculation, like you mentioned) and work from there. It might turn out, in a few months, that that new feature nobody uses anyway so it's dropped. This is easier if you obey: 6) Think at product level