>I agree that there are many approaches to solving a problem that will result in the correct answer. However, often times we take shortcuts that lead to maintenance issues or inability to extend the application. This is called technical debt. Sometimes it's acceptable to take on that debt. I can't comment if any of the solutions fall into the issues I just mentioned because I don't have enough understanding of the application. Only one person can figure that out. My original comment was made to cause additional thought into the implementation.
>

I don't disagree with what you're saying. My only comment is that constraints/requirements of an existing environment sometimes lead to technical debt.

Two of my recent clients have been involved in acquisitions where legacy applications came into the picture - and until those legacy applications are rebuilt (assuming that even happens), the restrictions/constraints prevent more "ideal" approaches.

I hesitate to say the words, "it's acceptable to take on that debt"...instead, it's more a matter of, "we have no choice because management is essentially forcing us to take on that debt". Sure, management might deem it acceptable, though they'll often be the loudest to bitch when developers are still posting hours to tasks that are tied to that debt. This scenario is probably my biggest frustration of this profession.