There may be any number of reasons why these things have withered on the vine. They may have been too grandiose, too different, too ahead of their time, or too incompatible. They may have been written by a junior developer who had not yet earned the necessary respect. Whatever the reason, they have not only become blemishes of inconsistency in the code-base, but they are also monuments of disappointment. They are a constant reminder of how a certain someone failed to convince everyone else that their idea was better than the status-quo.If you’d like to avoid having this happen to you, I recommend that you follow what I refer to as
The Humility Principle:
When writing a class that is intended for reuse by everyone, design it and name it as such, but scope it as locally as possible.
So, for instance, if you are creating a new base class from which you think all report classes should ideally be derived, go ahead and call it something common, like
ReportBase. Go ahead and design it in a common way that makes sense for it to be reused by all report classes. That’s all good, but don’t then make the mistake of assuming that everyone else will use it. Don’t put it in a high-level common library or namespace. Place it in as narrow of a library as possible. Feel free to use it in your own code as often as you want, and feel free to let people know that it’s available for use, if they are interested. If it proves to be a good idea, and your teammates decide that they want to start adopting it in their code too, you can easily promote your common class to a higher-level library or namespace.
When you follow the Humility Principle, your good ideas will grow organically and expand as their worth is substantiated through actual use. Your less than perfect ideas, on the other hand, can be improved or replaced in private isolation without causing you any undue frustration or shame.