The Humility Principle

It’s a common problem, especially in smaller companies—the source code is littered with grand ideas which never went anywhere.  These abandoned sections of the code were, of course, written with the best of intentions.  They were placed in high-level libraries and namespaces.  They were given bold-sounding names.  Their authors intended them to be utilized, some day, by the rest of the code as first-class shared components.  They may have even been superior in every respect. However, for one reason or another, they were never adopted by the rest of the development team.
 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.

Share This:
Facebooktwitterredditpinterestlinkedintumblr

Steven is a senior software engineer with experience developing stable, mission-critical applications for the public-safety market since 1998. He has been awarded the highest level as a Trusted User by his peers on StackOverflow. He is the author of Herding Ocelots, a blog aimed at providing help to software development managers.

Posted in Best Practices Tagged with:

Leave a Reply

Your email address will not be published. Required fields are marked *

*