pwr-electronics

I think your examples agree with my point: You found minimal-time solutions that haven't caused continuous suffering afterwards, and can be easily removed when the root cause is fixed. That's a good result.

I'm still trying to challenge your assumptions. Why does a different solution necessarily require expanding the scope of work? Like you said, that's where experience helps to have those skills in your toolbox. Doing things better doesn't have to be harder.

Maybe pdf numbers are sightly annoying in the modern age of writing.

My whole point is that you don't, because there aren't always just two options. That's the false dilemma logical fallacy.

I'm saying you can fix problems without dropping everything and redoing work. You're allowed to problem solve and work with people to create a third option. And you can prevent new ones by learning and strategizing.

The choice between refactoring and money-generating work is a false dilemma. There are other options, and the developer doesn't have to make that decision or carry out the work all on their own.

Does the company have any in-house guidance on the application domain? Or is it all external feedback so far?

Riveting

The business opportunity is in software that's inseparable from the hardware. Academics won't work on that because they don't do product development.

Of course there are contradictions. I'm talking about journalistic style in magazines. You're talking about something else.

I'm running out of ways to explain myself, so I'll just reword and summarize this thread from my perspective:

OC: Is it broken?

Me: No, they make generous interpretations to claim that it's broken.

You: With a generous interpretation, they can be said to break ...

Like I said, we're not having the same conversation.