Suppose that you're a programmer for a company of a thousand employees that makes embedded systems for some market. You're frequently tasked with fixing automated tests written by QA.<p>The test framework used to test your company's hardware system is a real bear to work with. It was written in Java by some guy who talked his way into a job, who didn't actually know Java. When he left, it was inherited by other bad programmers, including people in QA.<p>The key to creating good API's and frameworks, according to Scott Meyers, anyway, is making them easy to use correctly, and hard to use incorrectly. This test framework is neither of those things. The framework is so bad that, when a test fails, no one is really sure if it's a bug in the product, in the test, or in the framework; there's barely any logging, and exceptions are always swallowed, so no one ever really knows what happened.<p>Unfortunately, because this test framework isn't customer-facing, management won't allocate time to improve it.<p>Barring looking for another job, you see two options:<p>1. Ignore how bad it is, do the bare minimum to get these automated tests working temporarily, and get the tasks off your plate.<p>2. Revamp the framework from the ground up -- a big task -- in your free time, with the hopes that your laundry list of gripes can be resolved, and you will no longer be asked to fix automated tests based on a crappy framework.<p>What do you do?