On Standards and Best-Practices
Who should you trust?
The nature of the beast
You will often hear terms like “standards” and “best-practices” tossed around in your professional life. But have you ever wondered what those terms mean? I find that both terms are really used to further a developers argument when convenient, but often cast aside when they might work against proving a point.
According to our good friends at Merriam-Webster, a best-practice is defined as followed:
A procedure that has been shown by research and experience to produce optimal results and that is established or proposed as a standard suitable for widespread adoption.
As far as a standard goes, let’s define it like the following:
A set of rules and guidelines that are adopted and applied to the production of a deliverable.
That’s my definition of a standard since I couldn’t really find one that fit nicely.
Those terms seem clear, but who defines the best-practices and standards? Are best-practices/standards a universal good, or can they also work against you?
Standards
The interesting thing about coding is that it’s really part-art/part-science. The science part of it includes the unambiguous bits:
Typing
Compile-time errors
Static analysis
IEnumerablevsIQueryablebehaviorsVersions of C#/Dotnet
The art side includes the following:
Solution/project structure
Class/struct/enum/variable/folder naming/casing
varvs type-name declarationsSingle-line
if/using/namespaceWhitespace
Folder organization
Semantic versioning
Code comments
What standards attempt to do is to force the art-side to be consistent across developers. To aid us in that endeavor we often use linters for C# and other languages (notably JavaScript). One standard linter comes in the form of ReSharper (R#) which will remind us in the IDE that we’ve colored outside the lines. When opening a project that doesn’t use a linter, it’s plainly obvious because my R# lights up like a Christmas tree.
Automated builds can hook into the linters and reject a pull-request (PR) simply based on something failing the standard (but otherwise works).
In general, standards are much easier to enforce (than best-practices) because some sort of recipe can be applied to code without knowing exactly what the intent of the code is. A standard can be added/removed by updating the linter. Of course you will have to argue amongst yourselves about spaces vs tabs and single-line statements.
Best-Practices
Best-practices are a bit murkier and we often code with the innate idea that we are coding with best practices in mind but often we are choosing a self-serving path. Topics that carry “best-practices” are much more contentious, consider the following list and imagine what the best practices would be:
Dependency Injection
Unit Testing
Encryption/Hashing Algorithms
Credential handling
Personally Identifiable Information (PII) handling
Payment Card Industry (PCI) handling
Personal Health Information (PHI) handling
Cookies
General Data Protection Regulation (GDPR)
Design patterns (Domain Driven Design, Anemic, Onion, Vertical, etc.)
CSRF, XSS, input validation, SQL injection
So obviously there are a lot of compliance related items in the list above. In order to determine if you are following “best practices”, you have to select an authority on the subject. Authorities can range from government entities to vendors to some popular blogger. Each authority may have their own interpretation of best practices. The weight of the authority can play a big role in determining which practice you adopt (as well as any consequences for ignoring said practices). The point is, there may not be one sole ubiquitous best-practice.
But what about non-regulated things like design patterns or unit testing? How do you select an authority for that? You of course could choose any authority you want or go your own way. OWASP and NIST are excellent authorities on cyber-security that you should be aware of.
Should you always choose Microsoft’s best-practices?
It depends of course. If you trust Microsoft, then you’ll likely align with them in most respects. However the caution I would provide is, Microsoft is like any other for-profit company and has it’s own grand plans. There’s been many times that I’ve stumbled on classes in Microsoft SDK’s that provide no abstraction for a popular class. Does this imply that Microsoft doesn’t think you should use abstractions? Maybe, but I think the conventional wisdom is to provide an abstraction for any public class. But then again, maybe that’s just Kevin’s best practice :)
My computing journey started with Microsoft in the late 80’s as they aggressively pursued closed-source proprietary commercial software. Of course they now have cross-platform open-source offerings which has changed a lot of hearts and minds. Microsoft is an entity just like the one you work for. They make mistakes and have their own institutional dogma. It’s up to your organization to go along with them or not.
I can promise you that a Rails, Node or LAMP shop doesn’t view Microsoft as an authority on much.
Best practices are much more perishable than standards. Advances in technology and hacking ability make some of the regulated items only “good enough” for now. Older dev’s may try to impose older paradigm’s while newer dev’s may have cut their teeth on newer ones. Is it better to use an MVC server-side render or a MVVM modern JavaScript frontend? By including the word “modern” in the description of MVVM, we bias the conversation towards using Vue/Angular/React. Personally I like the MVVM paradigm but is it a best-practice? Who would decide that? This is where technology like Blazor might sway Microsoft to push it’s own technology one day.
How often do you add to your standards/best-practices vs evaluate and possibly remove them?
Too many and not enough
Without standards, we have chaos; with too many we have a gridlock bureaucracy. Organizations are faced with balancing innovation with consistency. Often times it’s like balancing an egg on a knife’s edge and we overdo one or the other creating a cognitive thrashing for developers.
If you want more innovation, you’ll want less standards. This inspires creativity at the cost of consistency. If you want more consistency, your innovation will suffer. I personally favor less coding standards and I’ve met folks who can only stomach absolute consistency across the board.
I find that the ideal situation is to let teams determine their own standards internally on a domain project. I don’t see a whole lot of sense with enforcing a standard universally across a company other than for sake of policy. Each domain should be unique and if you have a lot of hands in one-cookie jar; split that monolithic codebase up. Like anything else, challenge your own standards and best-practices. You may need to add, remove or adjust them as time goes on.
As usual, happy coding!