According to Dave Rich
The whole point of a having a standard is recording common practice.
[We] have a long history that other end users and implementers of the standard do not have. It’s easy for us to understand the intent, and search the LRM for justifications, but those other people do not have that benefit. And all the people in that environment (training, support, maintenance, AEs), are faced with these problems every day (and many times each day).
According to Brad Pierce
There are more answers to “Why Standards?” than just “recording common practice”.
For example, “Standards can fuel innovation by providing a common starting point.”
Importing Java-style interface classes was an excellent addition to the SystemVerilog language, but they were not common practice in SystemVerilog tools.
According to Dave
I’m not trying to say there’s no place for innovation in standards, it’s just that you can’t forget the underlying principle that brought everybody together in the first place.
I know that if you get a lot of engineers in a room they all will want to work on new and exciting ideas but you can’t forget about the foundation. My favorite analogy:: you can build the most advanced aircraft in the world, but it will never take off unless someone designs the rubber tires.
According to Brad
I’m not objecting to investing some resource into perfecting our rubber tires, I just don’t think the ones we have now are so defective that we can only dare taxi around the airport.
There ought to be a balance between maintenance and innovation, if only to fire up the enthusiasm of the participants. I don’t know anyone that wants to be on projects that have fallen completely into maintenance mode. Maintenance is an honorable and necessary function, and we all do some of it, but it’s thin gruel that should only be eaten as part of a balanced diet.