这绝对是主观的，但我想尽量避免它变成争论。我认为如果人们恰当地对待它，这将是一个有趣的问题。
这个问题的想法来自于我对“你最讨厌的语言的哪五件事?”问题的回答。我认为c#中的类在默认情况下应该是密封的——我不会把我的理由放在这个问题上，但我可能会写一个更完整的解释来回答这个问题。我对评论中的讨论热度感到惊讶(目前有25条评论)。
那么，你有什么有争议的观点?我宁愿避免那些基于相对较少的基础而导致相当宗教的事情(例如，大括号放置)，但例如可能包括“单元测试实际上并没有多大帮助”或“公共字段确实是可以的”之类的事情。重要的是(至少对我来说)你的观点背后是有理由的。
请提出你的观点和理由——我鼓励人们投票给那些有充分论证和有趣的观点，不管你是否恰好同意这些观点。
当前回答
不是工具的问题，是你的问题
每当开发人员尝试做一些新的事情，比如做UML图，任何类型的图表，项目管理，他们首先寻找完美的工具来解决问题。在无休止的寻找后，他们发现没有合适的工具，他们的动机就会枯竭。剩下的就是对缺乏可用软件的抱怨。这是一种洞察力，在没有软件的情况下，要组织的计划夭折了。
好吧，只有你自己在处理组织问题。如果你习惯了组织，你可以使用或不使用软件来完成(大多数人都不需要软件)。如果你不习惯组织，没有人能帮助你。
所以“没有合适的软件”只是没有组织的最简单的借口。
其他回答
不应该允许非开发人员管理开发人员。
更正:没有开发经验的员工不应该被允许管理开发人员。
尊重单一责任原则
乍一看，你可能不认为这是有争议的，但根据我的经验，当我向另一个开发人员提到他们不应该在页面加载方法中做所有事情时，他们通常会拒绝……所以对于孩子们，请不要再用我们经常看到的“什么都做”的方法了。
观点:显式变量声明是一件很棒的事情。
我永远无法理解让开发人员浪费大量时间追踪由变量名输入错误引起的运行时错误，而不是简单地让编译器/解释器捕捉它们的“智慧”。
没有人能给我更好的解释，“好吧，这节省了时间，因为我不需要写'int I;'。”Uhhhhh……是的，当然，但是追踪一个运行时错误需要多少时间呢?
使用Stored Proc易于维护和较少的部署与使用ORM是面向对象的方式，因此它是好的
我在很多项目中都听到过这种说法，当这种说法出现时，总是很难解决。
通过断章取义地编写伟大的程序，以狂热者的热情和错误的假设，这些都是铁定的规则，这真的让我很恼火。例如，“过早的优化是万恶之源”。
在我看来，许多技术问题和解决方案都是非常上下文敏感的，全球最佳实践的概念是一个谬论。
