I often encounter the following program while programming. There is a "partial" solution to a problem, which provides all the functionality that is necessary, but the documentation explaining said functionality and the behaviour of the solution is very dense and esoteric. Then, there is a "full" solution, which provides more functionality than is necessary, but the documentation doesn't have to explain why it doesn't work in certain cases, and thus is very simple and easy to understand.

Just as an off-the-cuff example, consider a C# method Foo(A a) that takes a single argument of type A. Let's just say there's an easy implementation of Foo, but it requires A to have certain properties, and the explanation for why those properties are necessary is long and complex.

The "partial" solution is at the beginning of Foo I simply check if A has the required properties, and then reject it if it doesn't. This, however, makes the documentation very complex as now I have to explain why it doesn't work for certain objects.

On the other hand I have the "full" solution, which is simply to make Foo work for all As, regardless of their properties. Suppose I theoretically could implement a Foo that accomplishes this, but it requires a lot more code than the "partial" implementation.

Which is better?

Maybe that's a bad example, but I run into generalizations of this problem very frequently in a lot of my larger projects. Which solution should I choose when faced with this dilemma (if either of the "partial" or "full")? Are there any general tips for preventing this situation from arising?

I often encounter the following program while programming. There is a "partial" solution to a problem, which provides all the functionality that is necessary, but the documentation explaining said functionality and the behaviour of the solution is very dense and esoteric. Then, there is a "full" solution, which provides more functionality than is necessary, but the documentation doesn't have to explain why it doesn't work in certain cases, and thus is very simple and easy to understand.

Just as an off-the-cuff example, consider a method Foo(A a) that takes a single argument of type A. Let's just say there's an easy implementation of Foo, but it requires A to have certain properties, and the explanation for why those properties are necessary is long and complex.

The "partial" solution is at the beginning of Foo I simply check if A has the required properties, and then reject it if it doesn't. This, however, makes the documentation very complex as now I have to explain why it doesn't work for certain objects.

On the other hand I have the "full" solution, which is simply to make Foo work for all As, regardless of their properties. Suppose I theoretically could implement a Foo that accomplishes this, but it requires a lot more code than the "partial" implementation.

Which is better?

Maybe that's a bad example, but I run into generalizations of this problem very frequently in a lot of my larger projects. Which solution should I choose when faced with this dilemma (if either of the "partial" or "full")? Are there any general tips for preventing this situation from arising?

I often encounter the following program while programming. There is a "partial" solution to a problem, which provides all the functionality that is necessary, but the documentation explaining said functionality and the behaviour of the solution is very dense and esoteric. Then, there is a "full" solution, which provides more functionality than is necessary, but the documentation doesn't have to explain why it doesn't work in certain cases, and thus is very simple and easy to understand.

Just as an off-the-cuff example, consider a C# method Foo(A a) that accepts a single parameter a of type A. Now, the "partial" solution would be that Foo works for all objects that are subclasses of A provided they are decorated with a certain Attribute, otherwise Foo won't work.

The "full" solution on the otherhand is to simply make Foo work for all subclasses of A regardless of whether or not they possess the required attribute.

The "partial" solution is easier to code, but the documentation is much longer and more difficult to understand because it requires an entire section explaining why only certain arguments work.

The "full" solution is easier to understand on the user-end, but much more difficult to code because now it requires an implementation that works for all objects.

Maybe that's a bad example, but I run into generalizations of this problem very frequently in a lot of my larger projects. Which solution should I choose when faced with this dilemma (if either of the "partial" or "full")? Are there any general tips for preventing this situation from arising?

I often encounter the following program while programming. There is a "partial" solution to a problem, which provides all the functionality that is necessary, but the documentation explaining said functionality and the behaviour of the solution is very dense and esoteric. Then, there is a "full" solution, which provides more functionality than is necessary, but the documentation doesn't have to explain why it doesn't work in certain cases, and thus is very simple and easy to understand.

Just as an off-the-cuff example, consider a C# method Foo(A a) that takes a single argument of type A. Let's just say there's an easy implementation of Foo, but it requires A to have certain properties, and the explanation for why those properties are necessary is long and complex.

The "partial" solution is at the beginning of Foo I simply check if A has the required properties, and then reject it if it doesn't. This, however, makes the documentation very complex as now I have to explain why it doesn't work for certain objects.

On the other hand I have the "full" solution, which is simply to make Foo work for all As, regardless of their properties. Suppose I theoretically could implement a Foo that accomplishes this, but it requires a lot more code than the "partial" implementation.

Which is better?

Maybe that's a bad example, but I run into generalizations of this problem very frequently in a lot of my larger projects. Which solution should I choose when faced with this dilemma (if either of the "partial" or "full")? Are there any general tips for preventing this situation from arising?