I am working with a group where part of the responsibilities is managing a certain set of configuration files which, of course, have the same skeleton/structure across different environments but different values (like server, user, this setting, that setting etc.). Pretty classic scenario...

The problem is that everyone just goes and modifies final, environment-specific files and basically repeats the work for every environment. Personally, I am offended to have to peform repeatable, mundane tasks in this day and age when we have technologies to automate it all.

So I devised a very simple procedure of abstracting the files into templates, stubbing env-specific values with parameters and then wrote a simple Perl script that, given a template and an environment matrix with env-specific values for each param, produces the final file. So this is nothing special, cutting-edge or revolutionary -- I am pretty sure that 20 years ago efficient places did their CM like that.

However, that requires that changes are made at the template level and then distributed across different environments using the script and not making changes in the final environment-specific files. This is where I am encountering resentment as they feel "comfortable" doing it their old, manual, repeated labor way. Personally, I don't have a problem with them working hard rather than smart but the problem is when I have to build on top of someone else's changes, I have to merge their changes into my template from a specific file, which takes time and is grueling.

So my question is how to go about selling my method, which makes it so much faster in an environment that is resentful to change and where most things have to be done at the level of the least competent team member?

  • They probably perceive it as a power grab. There's no way that you can script their changes into yours? Nov 29, 2012 at 19:32

1 Answer 1


Some people feel any time spent in analysis is time wasted that could be better used doing "actual job". Disregardling the fact that that analysis time will pay off later.

They need to feel they are "doing, not thinking".

Chances are their boss just see them "busy", and that makes him happy.

The only way to convince them is to show them.

Prepare a demo, call a meeting, get a projector and show them.

Make it so good they cannot afford not to use it.

Show them numbers showing the time saved with your method.

Offer them support to implement it.

Show them an scenario when you can do a masive change in matter of minutes instead of days, and then roll it back.

  • initially, i was gonna use plain shell (lowest common denominator) but i couldn't quite accomplish what i was trying to do. Perl is the least of my worries though.
    – amphibient
    Nov 29, 2012 at 20:49
  • @foampile Getting them to see it as "administrator's thing" instead of as a "programmer's thing" will help. Could you tell me what is, specifically, that you couldn't quite accomplished with plain bash ? Nov 29, 2012 at 20:57
  • it required some lower level functionality i couldn't or at least didn't know how to do in shell. all of our machines have perl, that is the least of the problem -- the problem is the more abstract paradigm of doing the job instead of the old way that is more immediate but far more time consuming. it is the "who moved my cheese" type of situation, not shell vs. perl
    – amphibient
    Nov 29, 2012 at 21:16
  • @foampile I deleted the bash sugestion from my answer. Hope the rest of the answer is of any help. Nov 30, 2012 at 17:38

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.