Why use them?
It comes down to a few(-ish) very simple reasons:
- When it comes to engineering, industry, regulatory and compliance standards, the team, project, product and company need to be above reproach. Why put yourself in the position to defend your own self-contrived standards, let alone stand guard over them for years to come? Make your standards eq industry standards and then merely talk about your implementation of industry standards during an audit. Let the industry audit validate your use of industry standards, not your deviation from them.
- Spend your development budget inventing new things that make money for you and your company, not re-inventing things that already work and hoping for a raise for duplicative effort. The NIH (not-invented-here) syndrome continues to thrive in the software space. People who suffer from this disease should be coached away from NIH behaviours. If they simply can't get past it, they should be fired or sent to your competitor so they can waste all of their innovation money on command and control, maintenance and support efforts.
- On-boarding new staff costs money. Whether from the street or fresh out of university, on-boarding is a manageable expense based upon the chops said people bring to the table coupled with how well aligned your organization is with generally accepted, generally practised industry standards. People do not come out of university or off the street knowing your cultural idiosyncrasies. How can they? And in all cases I've personally experienced, they don't go back to the street any better for their time living inside your customized world either. Some won't even put it on their resume. Consider that people on the street are highly likely to know industry standards, so you don't need to teach it; merely interview for it. Likewise, fresh university graduates may not have all of the street experience of others, but they are not graduating naive to current trends, technologies and standards. Again, interview for it.
- Today's frameworks, tools, processes and procedures are all built upon a common set of standards. When you deviate from the generally accepted standards you increase both your operational overhead and your organization's risk exposure to breach, exploitation, potential litigation and liability.
- You're simply not as smart as you think you are. The collective is usually faster, more comprehensive and generally smarter than the individual and using industry standards inside industry tools enables teams to move more quickly and correctly than the inverse. If you can't see that, you shouldn't be leading.
Personally, I'm selfish. I like to go to sleep at night in peace. Most of the people I enjoy working with think like this as well. In order to meet the selfish goal of sleeping in peace, simplicity is required.
In order to be simple we don't just need to eliminate complexity, we need to prevent it. Guard against it. Using what exists every time possible, and automating most everything based upon those commonalities, is the foundation for success, not success itself.
Why would I use a tool for something other than its designer's original and intended use if I have a choice? Why would I possibly contrive my own coding and formatting standards outside the bounds of the specific language or vendor recommendation? Under what circumstances would it make sense to witch my own frameworks?
There are seldom exceptions. It would be great to hear your comments regarding why it makes sense to invent your own context-driven standards versus leveraging industry constructs as a launchpad to get where you need to go.
It's sad to see, but some leaders simply don't get it. Forcing your teams to stray from generally accepted industry practises and standards to then maintain and seldom evolve custom-to-your-environment ideologies is a travesty. Worse yet, maintaining custom standards simply precludes your team mates, teams and operation from focusing on and helping the business rise to new challenges.
Think about it: Exactly how are you helping the business look out the windshield when you're spending all of your time polishing the tailpipe?