One-offs and edge case requirements are everywhere. The article entertains the idea of eliminating edge cases. Edge case requirements aren't the problem. The

One-offs and edge case requirements are everywhere. The article entertains the idea of eliminating edge cases. Edge case requirements aren't the problem. The problem is how you solve for them. This is a form of complexity management and fortunately there are a few good approaches that solve for most forms of complexity. The way I commonly approach edge cases is that they are dealt with by an additional rule (and possibly accompanying data structure) in otherwise existing similar common functionality. If current functionality is not sufficient then write new functionality to solve for and replace other existing insufficient functionality. This allows for consideration of edge cases as formal requirements while minimizing expansion of complexity. It is refactoring and not innovation. If there is a need for innovation and new functionality then the requirement is a dedicated feature instead of an edge case. The difference between a feature and an edge case is the different level of intentional overhead required for documentation, integration, testing, and maintenance.