Amen to this comment, I apologize if my previous comment went too far, it seems like we're overall on the same page, at least on some issues. > For example, so

Amen to this comment, I apologize if my previous comment went too far, it seems like we're overall on the same page, at least on some issues. > For example, some people write method names that aren't descriptive. It happens. I agree, and I would actually argue names don't matter. Well, they do, we should still pick good enough names, and never pick adversarially confusing names. But ultimately, code should be clear regardless of the name. Take a look at this Haskell talk for better arguments than I can write here: [1] Part of the reason why designing software that by definition cannot include bad behavior is such a powerful concept is because even when we inevitably name things terribly, the harm is contained. [1] https://www.youtube.com/watch?v=ZSNg6KNzydQ https://www.youtube.com/watch?v=ZSNg6KNzydQ > But the reality of writing software is that sometimes the stakeholders don't care about future maintenance and refactor cost Sure, but this part of the problem. As engineers, it's also our duty to explain to business people the implications of these. If ultimately the business decision is that "this thing won't matter in X years" then there is nothing we can do, but the limitations must be known and clearly communicated. Which, I don't think you disagree, but I didn't think this came out in your original post.