Module Maintenance

You can fight this disfiguring disease by keeping careful control of the growth 

of your modules. This is considerably harder than it sounds every module must 

grow, and every feature request meets someone's need. Your only defense is to 

adhere to a strict definition of your module's place in world. When a request for a 

new feature arrives, you must evaluate it against this definition. Ask the questions, 

 Is it a natural extension that merely allows the module to function better in its 

problem space? Or is it a move into another problem space entirely, a symptom of 

the disease? 

Saying no isn't easy. Particularly when a developer has gone to the trouble of 

coding a patch, it can be very hard to turn him or her away. Your best defense is to 

be clear about what you see as the mission of the module and why you think his or 

her proposed addition is outside those bounds. Another useful strategy is to try to 

determine the motivation behind the change there may be another module that 

user could use in conjunction to yours that would yield the desired behavior. This is in 

no way a failure on the part of your module no module can be all things to all people.

Often a request that must be denied can point the way towards adding exten 

sibility. Adding extensibility means giving the person requesting a new feature a 

means to achieve their goals, even though you aren't going to implement it for the 

person making the request. Of course, if each time you add extensibility you only 

deal with one feature request, then you haven't gained much. Instead your goal 

should be to deal with a whole class of requests.

As an example of adding extensibility, a key turning point in HTML::Template's 

development came with the addition of the filter option, which allows users to 

extend the supported template syntax. All throughout HTML::Template's life users 

had been asking for this or that special tag, each for its own special purpose. In the 

early days, I had no recourse but to respond that their special tag wasn't going to be 

part of HTML::Template and try to let them down as lightly as possible. But once 

the filter option was implemented, I could show them how to add support for the 

tag themselves. Not only has this improved HTML::Template's utility for its users, 

but it has also allowed a small number of extension modules to be developed that 

use the filter option to implement new functionality. All that, and the fundamental 

simplicity of the module itself was not harmed at all! By adding extensibility to 

address a class of problems, I was able to divert requests that could easily have 

resulted in feeping creaturism.

Another useful technique is to appeal to the silent majority of conservative 

users who populate most module mailing lists. Often a new feature will attract a 

number of radical proponents who will flood the mailing list with supportive 

arguments. If you allow your judgment to be swayed by the appearance of unanimity, 

you'll be doing the larger user community a disservice. Instead, appeal to them 

directly. Say publicly,  Do you guys agree with these nuts, or what?  I've found that 

when faced with the possibility that some craziness is about to be accepted, the 

wise hermits in the audience will come out of their shells.

14

143

3