3 ms·
Sure, you can invent a scenario where the term “best practices” is a half-decent term. I’m not speaking in some kind of absolute. I still think it’s not a very
by klodolph 2y ago
Sure, you can invent a scenario where the term “best practices” is a half-decent term. I’m not speaking in some kind of absolute. I still think it’s not a very good term here. It’s not really describing best practices, is it? It’s just describing the practices that the teams are choosing to follow.
I would name the document something like “development standards” or something like that. I’ve this called “meeting the bar” or “engineering excellence”. I like “meeting the bar” because the implication is that you haven’t succeeded if you don’t do what’s described. I like “engineering excellence” because it implies that you’ve gone beyond the minimum. I don’t like “best practices”.
I also wouldn’t insist that everyone must follow it. You have minimum standards (everyone must follow) and a set of expectations which are higher than that (everyone should follow). I think it is a kind of common error to make long lists of standards that everyone must follow. It’s better to prioritize. The minimum standards should be short and connected to the most critical concerns like security, privacy, or legal liability.
IMO, 99.9% SLA is not really that hard anyway, but I get what you mean. That’s like 2 whole hours of downtime per quarter.
- SpicyLemonZest 2y agoI pretty much agree with what you’re saying, although I wonder how much it’s a euphemism treadmill. You don’t hear people talk about gold standards much these days. I’ve definitely seen overstuffed practices docs that end up as pointless (and ignored) checklists.
- klodolph 2y ago“Best practices” is a bad term partly because it has some kind of gravitational pull that attracts junk, partly because you almost always need some clearer term (it’s vague), partly because it describes something that isn’t relevant. Alternative terms for your practices docs: just call it “development practices” or something. This makes it a little more clear that it’s not a dumping ground for every practice people think is good / best, but only for what people actually care about, which is the development practices that your team has adopted. You can say something like, “Best practices according to research is X, but our team is adopting Y because we believe Y is promising.”