No because I’d fix the easy to fix code, and make it work correctly. The other code is useful for sure. I mean people have built billion dollar businesses on crap software that barely works. And very rarely do they manage to fix them... I’m just suggesting I have a preference for what I’d rather work on. You might like code that works and is impossible to understand and sits there surrounded by an even more obtuse test suite (if at all), but it’s not something I enjoy is what I was saying. To some degree this is inevitable but I think it’s always worth trying to fight the good fight.

I look at it this way:

Most likely the code I write has a bug in it. Or, at the time of writing, the customer requirement is fuzzy. Or, I have a limited grasp of the problem domain. Even if it is not any of the above, most likely there will be a change in a business requirement that impacts the code.

So whenever possible, I opt to write code that is either stupidly obvious, trivially testable, or easily replaceable.

You have explained it much more clearly than me! Thanks.

This is my extreme counter example:

What is better (A) a compiled bug free binary, or (B) well written source code that has a few bugs?

If you want to keep developing the software, the answer will always be (B).

This is not generally true, but strongly depends on the domain.

I which domains is it practical to add features to software you don't have source code for?