In general, when we change things, we hope to derive benefit from the change (Shocking!). Sometimes the benefits are greater than others, but that doesn't mean we shouldn't at least consider doing them. After all, your potential benefits when trying to solve a problem cover quite a range:
- Do no harm. Okay, so you're not getting anything, really, but at least you didn't make it worse. Like a doctor, as an engineer working with a system, it's kind of the least you can go for. Sometimes this is the unintended effect of a change ("but we really thought it would do something!")
- It's not much, but it's easy. This is the entry to the land of non-zero benefits; you're getting something. As long as the cost isn't much, it's not necessarily bad if the benefit is low, too.
- It won't fix it, but it'll help. This change is intended to be partial. Diagnostic changes generally fit in here. You're not really trying to fix the problem, but it might help the user and it will help you get to the bottom of whatever's going on.
- It hides the symptom. Here we're trying to alleviate pain, even if we don't resolve the underlying problem. In some cases, this is good enough; it really depends on what the underlying problem is.
- Fixed! This is usually what you start out aiming for. Sometimes you can't get here, because fixing the problem might have unacceptable side effects or untenable requirements, but often you can achieve resolution.
One of the classic ways to make a problem more frustrating is to keep making changes and not fix the problem. A lot of times this frustration happens because you're not clear on the intended effect of your changes. So slow down for a second, think about what the change is going to do, and communicate it to the person (or client or team) having the problem; it'll help keep frustration down. And that's good for everybody.