What Would You Do? | Hacker News Reader

What Would You Do?

2 pointsjfe8 comments

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.

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.

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.

Unfortunately, because this test framework isn't customer-facing, management won't allocate time to improve it.

Barring looking for another job, you see two options:

1. Ignore how bad it is, do the bare minimum to get these automated tests working temporarily, and get the tasks off your plate.

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.

What do you do?

Looking at it from management's perspective, if you improve their framework, it will have the following costs:

1. Cost for you to make it.

2. Cost for QA to learn it.

3. Cost to convert previous tests to new framework, if necessary .

4. Cost for delays on fixing QA's tests.

5. Cost for developers and management to receive QA's results later than expected during development/training.

Essentially, the question you have to ask is this:

In the process of improving this, how many tests will be delayed and by how much time? Will doing this save or expend resources over the duration of the project?

If you can answer that question, and the answer is that it will save resources - do it. Break down the costs and benefits to them from a program perspective. Understand them at their level and they will likely listen to you. Keep in mind though - their goals aren't always what you think they are.

You forgot an option #3. Hone your pitch to management to get them to give you the time you need.

Honestly I'd probably look for a new job, but with that option off the table #1 runs the risk of you looking bad doing the bare minimum and having truly failing tests that pass the suite. #2 runs the risk of you doing a ton of work for free only to get a pat on the back and maybe a "good job" email.

What makes your management tick? Is it happy customers? Frame the discussion with "We had 47 customer impacting bugs that were missed by the test suite last month." Is it cost savings? "My team spent 312 man hours last quarter fiddling with the test framework when you could have been moving the product forward or fixing actual bugs".

Just because it's not "customer facing" doesn't mean it isn't "customer impacting".

Management is fixated on On-Time Delivery. We do have metrics showing that QA spends a lot of time re-running automated tests, but there's no direct proof that shows that the crappy framework is the cause.

Ask yourself why management is fixated on it. What is their business case? One clue that they have a solid one is their willingness to pay people to do something that sucks.

How do you want to live professionally? Having the soft-skills to manage-up and explain things to non-technical senior management is a necessary part of your job. They deserve your best recommendations. If they don't get it or give inappropriate push-back, that's a sign your talents are best employed somewhere else.

>that's a sign your talents are best employed somewhere else.

Or your recommendations aren't presented well or your recommendations are presented well but there are higher priorities for the business.

The best way to foster communication is first seek to understand and then be understood.

1.

Track your time. It is likely to show there is no business case for 2.

On the off chance it does, then the business case will be backed by data. But odds are that there won't be a business case.

Reply on news.ycombinator.com