Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.
Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.
Lost your password? Please enter your email address. You will receive a link and will create a new password via email.
Please briefly explain why you feel this question should be reported.
Please briefly explain why you feel this answer should be reported.
Please briefly explain why you feel this user should be reported.
When is it the right time and when is it the wrong time to take the quick and dirty approach versus the proper elegant solution?
This started from the comments on my question: Decode Base64 data in Java.
I wanted a way to do something using only internal Java or something I wrote. The only built in way is to use the sun.* package which is unsupported. So when is it the right time and when is it the wrong time to take that approach?
In any situation, you have to balance the time that will be spent on solving the problem, and then the time that will be spent in maintaining that solution. If the lifetime of whatever you do is expected to be lengthy, then the extra time spent up front to do things the right way will, presumably, be easier to maintain and will save you in the long run.
However, if there are time constraints, the penalties for going over may far outweigh the maintenance cost. For example, if you MUST get a product out the door, do a quick-and-dirty solution now, and then log it as a bug to get fixed later in a patch, or the next version. That will require you to re-do the work, but like I said, it is all a balancing act, and often driven by cost at it’s root.