Beefy Boxes and Bandwidth Generously Provided by pair Networks
P is for Practical

OT: Getting people to use tools

by logan (Curate)
on Apr 30, 2003 at 20:43 UTC ( [id://254460] : perlmeditation . print w/replies, xml ) Need Help??

OT, but I don't know where else to turn. I just got out of one of the most frustrating meetings of my career. I develop test tools (in perl) for a startup company. For the last 3 years, I've been writing tools to automate testing, benchmarking, configuration, and generally make people's lives easier. The problem is that I can't get people to use the tools.

A typical development cycle runs like this:

  1. I am assigned to develop a tool.
  2. I solicit suggestions rom the end users as to what the tool should do.
  3. I write the tool.
  4. I present the tool to the team, demo it, and ask for feedback.
  5. Blank stares and I'm the only one who uses the tool.
I've tried everything I can think of to get buy-in from my co-workers. I tried asking them what they want automated, and got blank stares. I asked each of them individually what tasks they did that were repetitive, and asked if they'd like tools to do it for them. When I produce these tools, they won't use them, and can't explain why not.

Today, I came up with what I thought was a foolproof system to make everyone's life easier. I wrote a tool to install daily builds. All the user needs to do is call it from the command line, and walk away. I estimate it would save each team member 1 hour a day, and I'm the only one who has to do anything. I write the tool, I install it, I configure the servers to accept it. Result: no buy in. Nobody wants it except the team manager and I. I got resistance on every minor point, from using a naming convention for file systems, to having a single repository for testcases. And when pressed for explaination, they'd just say "Never mind" in that "I'm not going to fight you, I'll just not do anything" way. I just don't get it. I'm trying to make their lives easier, and nobody wants to be helped.

I'm in a real Dilbert situation. I'm trying to improve the way we do our jobs to everyone's benefit, and there's so much resistance that I'm having trouble seeing the point in trying. This feels like the moment when Dilbert turns into Wally.

Has anyone else faced this? What can I do to get people to accept better hammers?

"What do I want? I'm an American. I want more."

Replies are listed 'Best First'.
Re: OT: Getting people to use tools
by traveler (Parson) on Apr 30, 2003 at 20:58 UTC
    In my experience people don't use time-saving tools like this because:
    1. They don't like them (e.g. the user interface)
    2. They don't trust them
    3. They don't like the tool writer, personally ("I wouldn't use anything Joe wrote")
    4. They feel that if they use the tool, they'll have more time to do more real work instead of mindless simple stuff.
    A correlary to number 4 is job security: if you are so busy doing stuff (even stuff a tool could do), you must be very important to the success of the company.

    It seems that number 4 might be an issue there. I have seen people resist CVS for reason 4...

    HTH, --traveler

      There is another possibility... One trap that I admit freely I fall into occasionally.

      It's the "I'm afraid I'll forget what I don't use" mentality.

      I know, intellectually, that there are lots of time-saving shortcuts out there, but I often reject using them out of some fear I might forget how to use the old-fashion, long way...

      Because one day, I'll be on some *other* Unix box that doesn't have the shortcuts installed, and I'll find myself looking like an idiot because I don't remember the address of a box I have to ssh to...

      If I *always* do it the long way, then if I'm on another box, I can count on being able to do it correctly there as well...

      I didn't say it was a *good* answer :)

      I have seen people resist CVS for reason 4

      Funny you should mention CVS. I can't get them to use that either.

      "What do I want? I'm an American. I want more."

      I'm astonished you don't mention inertia and laziness. These are the top two reasons for me, and almost the only ones :)

        For me, tools often overcome laziness by making things easier unless I need to learn a lot to use them. Inertia can be a factor for me, too, but time saving can overcome that pretty easily if I can see the saving.


Re: OT: Getting people to use tools
by dragonchild (Archbishop) on Apr 30, 2003 at 21:23 UTC
    Having been in a similar situation, I found the problem was me ... in a way. I was too productive. People, especially testers, do not believe the speed by which bug-resistant code can be developed in Perl, especially by a maestro. Remember - these people find bugs for a living!. They know how fast software takes to be developed and how many iterations it has to go through to be relatively decent. I mean, they know more than you do! Duh ...

    At least, they think they do. They don't really understand the paradigm shifts that are enabled with Perl. And, you're extremely gung-ho about what you're doing (which is good). Unfortunately, you're probably coming across as a cowboy who's just going to make their life a living hell.

    The solution I used was this:

    1. Back off. They know about the tools. You pushing will not help increase acceptance.
    2. Find one user and make them your friend. Get to know them personally. I mean, literally, go out for beers or to smoke breaks together.
    3. Find out what that one user complains about the most. (Also at this time, discuss with your friend your frustrations. Maybe they have insight for you.)
    4. Ask them if you can make a tool to help out and be with your friend to hold their hand.
    5. Write the tool. This tool has to be 110% bug-free. I cannot emphasize this enough. This is probably your only chance to make a good impression.
    6. Work with your friend and get them to use it. Make it part of their daily life. Be willing to make the stupid features. DO NOT TELL THEM WHAT IT TAKES, OTHER THAN "Yeah, I can do that."
    7. At this point, you have started the change. Lather, rinse, repeat.
    And, good luck. I truly do feel your pain.

    We are the carpenters and bricklayers of the Information Age.

    Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

    Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

      Nice answer....You didn't know a guy named Machiavelli by chance?

      Come to think of it, I drink beer with all of the people I write code for.


        Machiavelli may have been an asshole, but he was an asshole who also happened to be right. Of course, I personally work towards creating a world where he's wrong, but that doesn't mean I don't work within the world I was given. :-)

        We are the carpenters and bricklayers of the Information Age.

        Don't go borrowing trouble. For programmers, this means Worry only about what you need to implement.

        Please remember that I'm crufty and crochety. All opinions are purely mine and all code is untested, unless otherwise specified.

Re: OT: Getting people to use tools
by halley (Prior) on Apr 30, 2003 at 20:49 UTC

    You've already answered #1 and #2, just bear with me.

    (1) Were you assigned to make the tool BY the future users? (Or was it by some lead figure or boss?)

    (2) Does your tool get exactly the same results as what they got, only with fewer steps?

    (3) If not, then why did you make a tool for them?

    You can't change other people's behavior. They'll use the tool if they feel like it. Most people don't want to change their existing methods for some new method they haven't used, even if they don't like their current approach or results.

    Update: If all of your managers sign off, and you decide that it's for the best, then "break" the other users' existing methods: change the system so their old methods won't work anymore. They'll start coming to you with the "now, how does this work again?" questions.

    [ e d @ h a l l e y . c c ]

      1. The initial assignment came from a manager. Since her departure, 2 subsequent managers have weighed in saying they want this.
      2. The tool gets the exact same results, and gives the option for more (install the build, give option to populate the system, option to run automatic build acceptance testing). And, instead of 30-40 steps, it's one step.

      Worse, this isn't an isolated instance. I've created dozens of tools, large and small, and I get the same thing every time. I don't think it's the technology that's an issue. I think it's attitude and mindset, which are far more difficult to change. Honestly, this isn't so much a perl question as a social engineering question, and I am both frustrated and baffled.

      -Logan, turning into Wally
      "What do I want? I'm an American. I want more."

        I feel your pain. A lot of my job is project work/tools. While they are adopted and used some of the time, some of them just sit there.

        I think the key thing for tools like that is not only management buy-in, but a policy that says it must be done that way. If using your tools are optional, people will do things the same way just to avoid learning something new. Something that I find useful in getting people to adopt something new is documentation. If they've got a reference (especially a quick reference), it seems to help.

        It is a weird phenomena though... You hand somebody something that will make their lives much easier and they'd rather to do it manually.

Re: OT: Getting people to use tools
by Zaxo (Archbishop) on Apr 30, 2003 at 21:05 UTC

    It's probably the team manager's job to enforce the development procedures he wants.

    That said, maybe there is a reason people don't want to use your tools. You should look at how they work to see.

    Do your tools remove diagnostics and other build information from view? Many people like to follow a build and read the messages, using the time to think about what's happening and how to improve it. They may consider that time better spent than, say, attending some meeting while thing happen unseen.

    Do people need more control over the build than you give them? Have you left room for personal preferences? Most programmers have habits of work which they have built by experience. Not all may be optimum by some standard, but all serve to make the programmer comfortable.

    I recommend that you evaluate your goals, not by asking people, but by observing them. There are an amazing variety of better hammers, most having nothing to do with nails.

    After Compline,

Re: OT: Getting people to use tools
by Abigail-II (Bishop) on Apr 30, 2003 at 23:42 UTC
    I'm trying to improve the way we do our jobs to everyone's benefit,

    Well, that's what Microsoft saying as well. There are many reasons people don't use stuff the vendor claims is good for them. To name a few:

    1. They don't trust the tool.
    2. They don't trust the maker.
    3. They think the learning curve is too high.
    4. They don't think there's a benefit.
    5. They think they lose control.

    And it doesn't really matter whether it's true what they think. It's the perception that matters. What's your history of making tools? Have you made tools before that weren't as good as you thought they were? Is the UI good (in their perception, not yours)? How is the documentation?

    What can I do to get people to accept better hammers?

    Techies make lousy sales people, but you get people to accept hammers (any hammer, not necessarely better hammers) by convincing them that a) they need to use a hammer, b) your hammer is better than what they use now, and c) the upgrade is worth it.


Re: OT: Getting people to use tools
by demerphq (Chancellor) on Apr 30, 2003 at 23:11 UTC

    *sigh* So it's not just me. ;-)

    Seriously though, I have been there and it wasn't much fun. Part of it is personality, some people are just too loner to work effectively as a team. Part of it is eclecticness, the people who you deal with aren't on top of their own issues so arent going to make much of an effort to even think about yours. Even if it helps them.

    After a long time of frustration I found a few approaches that improved the odds. One was to clearly demonstrate that something horrible wouldn't have happend if they had used my modules (or just as likely a CPAN module I had suggested). Saying in a meeting "I hate to say it, but I published a module that would have caught that problem, but nobody bothered to use it, anyway, why don't you use it now and problem solved?" can do wonders. :-)

    Another was to make the code so simple and easy to use that it was hard to justify using anything else. I found that the more time I put into the interface of my code the more likely they would use it. Hand rolled imports may have a bad reputation, but the import() interface to a module presents a perfect place to add syntactic sugar that makes a module so much more palettable. Many commonly used and popular modules have hand rolled interfaces for exactly this reason. Comprehensive reference and samples in the documentation really helped as well.

    A third way that worked sometimes was occasionally to just replace chunks of code they had written with a wrapper that called out to a module. Eventually they would end up in the right part of the code and notice a comment along the lines of "# Someone reinvented the wheel!" and the new (and usually quite small) code. They might get mad, but its hard to argue when you can say "but you've been using it for months!"

    But the fact remains that you can lead a horse to water, but you can't make em drink.

    Er I have to add one last story: I worked with another guy who absolutely refused to let anybody work on his code or access his boxes, working with him was practically impossible, he wouldn't help you and wouldn't let you help him. Eventually he had to be replaced and when we finally looked at his code it was the nastiest mess I had ever seen. I think the reason he was so solitary was the fear that someone might discover his stuff was hanging by a thread. Maybe your colleagues don't want to use your stuff because they see you and your methods as a threat. If they have to use your stuff it might show that they aren't quite the hotshots they would like the managment to believe.

    Anyway, best of luck.


    <Elian> And I do take a kind of perverse pleasure in having an OO assembly language...
Re: OT: Getting people to use tools
by LameNerd (Hermit) on Apr 30, 2003 at 20:56 UTC
    Maybe the people you are developing these tools for are
    command line phoebes!. You may have run into non-analyticals.
    You say you "just want to make their lives easier", but you thought
    that maybe their lives are just struggle? You need to make them feel
    smart and important (If you cannot have them fired!)
    That is the definition of "Buy In".

    Try making your code UI/browsers based.
    I know you know that this is easy but they don't know that. ;)
      Maybe the people you are developing these tools for are command line phoebes!

      Ah, yes. We're on the same page. I actually did do a web interface, hoping that would solve the problem. No luck. I work in a unix house, and one of my end non-users is total command-line guy. He won't use aliases, command-completion, or shell prompts. I've tried to show him shortcuts ("You know, you could just use the alias 'll' for 'ls -lA'. It's already set up for you in your .tcshrc file."), and he won't do it. Even after demonstrating how it will make their jobs easier, nobody wants to play.

      "What do I want? I'm an American. I want more."

        I wonder the same thing about command line users (even occasional users) who have no clue about file-name completion. It drives me nuts to have to type a long multi-node file name, and can't understand why other people just do that instead of finding something that avoids it.
Re: OT: Getting people to use tools
by runrig (Abbot) on Apr 30, 2003 at 21:54 UTC
    I just don't get it. I'm trying to make their lives easier, and nobody wants to be helped.
    I'm reminded of a quote from Garth of Wayne's World:
    We fear change
    I'm convinced its universally true. People are resistant to change, even if it saves them hours or days of work. At work here, when we make code changes, they often have to be applied to several different custom code bases, and these changes were being done manually and could take days hours or days of work (forget for the moment that we should be using CVS). So I wrote some scripts utilizing diff and patch (yea Larry!) to turn hours of work into minutes or days into hour(s).

    I documented them, I wrote step by step instructions, and found they weren't being used until I stepped through the procedures with each programmer until they finally saw the light. The only programmer that was still not using the scripts worked offsite (and is no longer in the picture anyway). We only have a few developers here, so this strategy may not work with you :-)

      Definitely I agree with this. Despite knowing better, I didn't make the transition to various better tools for a long time simply because, well, it's a lot to learn. I knew the outcome would be favourable, but I couldn't make myself do it - at least, "not now - later".

      Makeshifts last the longest.

Re: OT: Getting people to use tools
by chromatic (Archbishop) on Apr 30, 2003 at 22:06 UTC

    Hmm, I've never really had trouble with that. You should come visit my workplace sometime and see how we do things.

    (Yes, I'm being subtle. Sometimes, the best thing you can do is just use the tool and wait for people to notice. It helps if you can convince them to work with you and notice how much time you aren't spending doing stupid little things. You do have to wait patiently for them to figure out why and to ask for your tools, though.)

Re: OT: Getting people to use tools
by artist (Parson) on Apr 30, 2003 at 21:01 UTC
    Hi Logan,
    I would suggest to check : Re: Lost in the Translation. Some good points there about homework for convincing the management

    Besides that also help yourself. Find out what other similar experiences have in your office and learn from it, especially how the help from an individual employee is perceived for the major benefit.

    Your noble intentions and applicability of tool is not everything. There are many other factors which work for the acceptance.

Re: OT: Getting people to use tools
by perrin (Chancellor) on Apr 30, 2003 at 22:26 UTC
    Resistance to change of any kind is pretty much universal. If they have a way of doing things that seems to work for them, naturally they are not interested in investing time to learn your new way, even if it will eventually save them time. Maybe they don't consider the work you're saving them from difficult or time-consuming. But most likely, they just don't want to spend 10 minutes learning how to use your tool if they don't have to.

    This kind of resistance can be seen elsewhere (using CVS, using CPAN modules, etc.), and I don't know any silver bullet to solve it. You can try winning them over one at a time, or your manager can tell them they have to use it. I've seen teams waste tons of time or use terrible tools because of unwillingness to try new things. Many won't change if they have a choice in the matter, but once they try the new thing they'll realize how silly it was to do it the old way.

Re: OT: Getting people to use tools
by crenz (Priest) on Apr 30, 2003 at 21:08 UTC

    That the management is on your side is a big plus. However, it is hard to change people's habits. I think the final step that motivates you to learn something new for a lot of people is when the old way to do it becomes too cumbersome. I started using CVS when it was just too much effort to back up different versions, find out when I made a certain change etc. :). So breaking the old system is not too bad an idea...

    I'd try to talk to management about this. Develop a plan together to introduce a better system. If your company is a professional development shop, I am sure they have coding guidelines, prescribed programming environment guidelines etc. It is hard to change a project that has already going on for a while. Why not choose a new project, maybe even with a couple developers that are still rather new to the company, and try to implement some of your changes there?

Re: OT: Getting people to use tools
by Jenda (Abbot) on Apr 30, 2003 at 21:35 UTC

    I don't know your coleagues, but I've seen too many people scared by the commandline. If all they have to do is to go to the prompt and start something why not put an icon on their desktops/launchpads/whatever. There's nothing as simple as a single (or double) click.

    Better yet ... don't ask even for the click. Schedule the morning build to run before they come to work in the morning and send them the log.

    Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.
       -- Rick Osborne

    P.S.: I know how you feel. Happened to me as well. They all agree the tool is great but wount use it. The only tools being used are those that run in the background as services/daemons.

    Edit by castaway: Closed small tag in signature

peopleware problem, not technical
by g00n (Hermit) on May 01, 2003 at 12:18 UTC
    The problem is that I can't get people to use the tools
    Hi Logan, looks like you've got some 'peopleware' Demarco, Lister, 2Ed, type problems rather than a technical problem. You say you are in a startup. Well looks like they have hired the wrong people (your co-workers). I've worked in startup(s) and there is nothing worse than closed minds in small teams you simple do not have the time, resources to waste.

    First who, then what ...
    If you read on current business *best practice*Good 2 Great [Jim Collins, is a good example, you will see that if you recruit the *right people* - you don't need to motivate, and micro manage them. The right people are more interested in creating the best they possibly can and open to *any* tool that can imporve work practices. Ever wonder how the Armed forces recruit?

    Confront the brutal facts ...(the Stockdale paradox)
    The second point is that maybe you may have to accept that your co-workers (and maybe management) are settling for *good enough* rather that shooting for world best?

    I could go on. Look around for another job. Don't waste your time trying to convice your co-workers. Remember the best leave when they see misalignment of core ideals between company aims, employees and themselves ...
Re: OT: Getting people to use tools
by allolex (Curate) on May 01, 2003 at 08:05 UTC

    Management should be pushing this issue, not you. This is a failure of management, not you. You are doing what you were assigned to do. If you personally see the non-use of your tools as a problem (as you obviously do) then you should take this to management.

    I've found that if you make the tool fun to use, a lot more people will latch onto it. I put a silly JavaScript rotating clock I found on the web into a screen output parser and web form interface I built---I would always see the screen up while my colleagues played with the clock (in a call center). And since they already had the input box in front of them...


Re: OT: Getting people to use tools
by particle (Vicar) on May 01, 2003 at 01:58 UTC

    perhaps you can change your audience.

    i mean, if it's allowable, and you think your code can benefit others, submit it to other communities, like the CPAN, or one of the code sections here. i know my current client's test group could benefit from automation. it may not help the people you work with, but it can help others. maybe that's something.

    oh, and if you haven't guessed, i'd love to see your work. then i wouldn't have to roll my own six months from now, when that work is scheduled for me!

    ~Particle *accelerates*

      I thought about submitting my finished code to CPAN or Perlmonks, but there's nothing publishable. The code is specific to the installation of Kasenna MediaBase. There are tricks and concepts I learned along the way, and I learned about a bunch of modules I'd never used before, but nothing publishable. Actually, the most surprising thing I learned was that there are no perl modules for driving package installation for Linux, Irix, or Solaris. Me, I figured that these modules would have been written years ago, but I found nothing.

      "What do I want? I'm an American. I want more."

Re: OT: Getting people to use tools
by draconis (Scribe) on May 01, 2003 at 14:14 UTC
    First I'd like to say that I think this is a great topic.

    My approach, the one that works for me and maybe not for everyone one is:

    1. Solicit the input of the target user group - have them become part of the design process. Forget what you think files/directories should be named (unless of course it would cause issues) - let them decide on the conventions, let them decide on interface - help them streamline the process to their liking.

    2. Since management wants the tools they must step forward and enforce the use - BUT - the user still will not use it unless they are contributors to the tool.

    3. It also seems to help me when I "lead" the user to the solution - this makes them feel like they came up with the idea - therefore making it more palitable to use - rather than having a tool "crammed" down their throats by management and their peers.

    Is this foolproof - no. But it will put the odds in your favor - or at least it has for me.

Re: OT: Getting people to use tools
by Your Mother (Archbishop) on May 01, 2003 at 18:56 UTC
    This could be for many reasons as everyone went over. Generally when intelligent people (your office mates?) do stupid things (ignore a clearly better tool) it's because of personal issues. I'm not saying this is your case, but there's a guy in my office who pesters a hundred developers on a daily basis with flip answers and style nazi advice to questions no one even asked. He's a good coder and he works really hard and he often puts out nice solutions. It's difficult for me to use them or even look at them b/c I don't see a tool. I see a smug know-it-all-who-doesn't-jerkwad winning. I'd almost rather re-write what he did from scratch for myself. Emotions make people do and think irrational things. So your interplay with your office might be worth examining. But mabye not. :)

    I do think there is one thing particularly that you could do no matter what the problem is: coach to the top 10%.

    If you get buy in from even one developer who the office sees as "guru" or "answer guy," I guarantee others in the office will look over and say: "What's that you're doing there? Say that's nice. Lemme try that."

    Unfortunately, the one who knows the most about a thing is often the worst salesman for it.

Re: OT: Getting people to use tools
by toma (Vicar) on May 02, 2003 at 07:44 UTC
    You could bribe your coworkers with candy. Try keeping several very large jars with several types of candy, or perhaps pretzels, at your desk. Give it away freely. People will feel obligated to give you something in return, and might at least be willing to try your tools.

    Be sure to replace the candy if it gets stale.

    If you want to be *very* clever, give away pretzels at your desk and drinks near their manager's desk. When they eat your pretzels and then go for water, the boss can ask, "so, how are those tools working out?" Just be subtle about it, don't start it all at once.

    It should work perfectly the first time! - toma

Re: OT: Getting people to use tools
by cciulla (Friar) on May 01, 2003 at 12:35 UTC
Re: OT: Getting people to use tools
by little (Curate) on May 01, 2003 at 19:30 UTC

    All the user needs to do is call it from the command line, and walk away.

    As I read that line of yours there just came one thing to my mind. Why not to use peoples lazyness to their efforts? :-) Just put the call to your script in each users environment logon procedures, be it a Windows or Unix Box, that should work.

    But hey, as I can imagine, the very first day a lot of angry people will (at least want to) meet you as the files they were working on (and wich they just by chance only the day before didn't finish to work on and hence didn't check in again, and we all know, that this only happens once in a lifetime, but nevertheless a genious work has been wiped out ...)

    But knowledge of an automated procedure will result in following the rules to not to break the procedure or in circumvention of the procedure, and as we all know, every programmer feels sometimes like root, erm, I mean good and is of course creative enough, to easily break the whole thingy.

    to summarize and to get back from humour to life's hard thruth: They fear that your tool could FORCE them to change the way they work in. As others said before: go and sell your product.

    Have a nice day
    All decision is left to your taste

Re: OT: Getting people to use tools
by chaoticset (Chaplain) on May 01, 2003 at 17:38 UTC

    My US$.02:

    What can I do to get people to accept better hammers?

    Well, hey -- like anything, you have to sell it. You start with the benefits to them, just like a salesperson, and end with that little ol' teensy tiny thing they actually have to do.

    Of course, no amount of selling is going to move refrigerators inside the Arctic Circle -- if the proposed tool-users find it to be "threatening" as people often find change, then you won't have buyers.
    You are what you think.