Possible but not Recommended.

We developers are capable of great and terrible things that can enhance or cripple a business and, for the most part, we're aware of that fact and try to put checks in place to keep everything within the bounds of supported techniques and tactics.

There are occasions, however, that require us to step out of that zone of safety and comfort for the greater good. Many times, we're lead down the path by those who make the rules, but warned that, while possible, the techniques aren't recommended and for good reason.  One should only step out of recommended practice if no other alternative exists and then, only with the fully educated support of all involved parties.

There are some basic guidelines to leaving the box:

• Never, under any circumstances, compromise security to simply make something work!
• Don't use an unsupported or deprecated technique just because it's easier.
• Before you implement such a solution, know how you'll fix it if it breaks.
• Test every aspect of your solution before taking it live.

The big takeaway is that if it can't be done without compromising security then it simply can't be done. With data breaches hitting some of the biggest retailers and web sites, there's just no excuse for compromising security for any reason. End of story. As a matter of fact, one of the few valid reasons for stepping outside of support is to enhance security in some way.

Have you ever used a table instead of div tags and .css files in a web page just because it was easier and faster than the preferred way of doing things? I have and at the time, I didn't think it was such a big deal, but that turned out to be a mistake when the site branding had to change with the rest of the enterprise. It's important to realize that moving away from recommended practice because we're familiar with an older, deprecated technique is not a valid reason and adds to the technical debt of our solution.

Did you know that you could fix a leaky gas tank on a car with a bar of ivory soap? You can and I have, but it's only a temporary fix. It's something that a short amount of time will undo and for that reason, you have to address the problem properly at some time in the near future or the fix won't be a fix for long. If you choose not to fix it properly, you must keep soap in the car to reapply the fix when needed and, besides being a pain, it never really takes care of the root problem. If you use an unsupported technique in code to fix a problem, it's important to find out why it isn't supported and address those reasons with a plan. In some cases, the fix might be an easy one as in the gas tank example, but you have to remember to check for the problem and know exactly how to fix it. Give you're customer the data and make sure they know how long the fix might take and what the ramifications are.

Testing, testing and more testing. It's important to do everything in your power to test these kinds of solutions from every angle and then, test them again. Even with testing, there may be ramifications in production that you didn't even conceive in dev and test.

Don't be afraid to look for solutions that are outside the box, but make sure there's not something in the box that'll work just as well.