Fog Creek Software
Discussion Board

Invoking Change

I just started reading this site after someone sent me the article "Painless Functional Specifications".  I must say that I am quite impressed with the processes outlined in that and other articles throughout this site. 

So, as a result, I've taken it upon myself to invoke change within my group at work.  My status in my company is about a mid-level programmer... so I don't have tons of clout. 

I would be interested in hearing what approaches are the least "painful" that people have had success with in invoking change within an existing work environment.  In particular, how can someone get "buy in" from fellow employees/bosses about making policy and procedure changes without "stepping on too many toes".

Tom Davies
Wednesday, December 19, 2001

The one way I know of doing this is to be known for doing lots of intelligent good work.

For one thing, at that point you have a significant codebase.  You have a bigger position to insist on things if your code already conforms to those standards.  (Just as long as you're not totally bucking project standards or being prima donna-ish.)

It's still political, but that's an example of good politics.

Wednesday, December 19, 2001

I'm in essentially the same situation.  What I have tried to do is lead by example, and have been met with some small success.  A daily smoke test, for example, got its start when I would religiously take the nightly build out each morning, do a clean install, and then send an email bitching about all the problems I could find with it in five minutes of playing with it.  Eventually a few people started asking, "shouldn't QA be doing that?"  Well, yes, but they weren't and I didn't have the clout to beg and cajole them into doing it.  But once they saw me doing it it dawned on them, "yes, this is what we need to do".

I've also been able to start some sort of code review process by partnering up with one of the more process-savvy developers in my group and sending her my code before checking it in.  So far the rest of the group hasn't adopted it, but I hope they do eventually.

One last thing you should do is seek out the brightest members of your group -- or of other groups -- and work as much as you can with them -- try to form your own group if at all possible.  What I've found annoying is that the composition of our groups is essentially random and that I have no control over who I work with.  Some of them are bright people.  Some of them are clearly not. 
The first group of people are the only ones who get anything done, the latter group merely gets in their way.  The latter group are the sort who believe that a state of perpetual chaos is perfectly acceptable and unavoidable because "it happens in all companies".  [No, it only happens in unsuccessful companies.]  In any case trying to get these sorts to adopt good development practices is a lost cause.  If these developers are on your critical path, then you're working with unreliable elements, and the best thing to do is to eliminate the dependency.

Wednesday, December 19, 2001

Talk to the person who does have the clout. Try to make them understand the benefits of following good procedure and standards. Dont try to win everything, just pick one thing, say, peer reviews and try to implement it.
Its amazing what can flow from this. 
If they dont back you up mentally burn them to a crisp with a flame thrower and start looking for another job.

Tony McConnell
Wednesday, December 19, 2001

I meant to say,
If they dont back you up - mentally burn them to a crisp with a flame thrower and start looking for another job.

I'm not advocating any real violence of course :-)

Tony McConnell
Wednesday, December 19, 2001

I've been in a similar situation at work, and the best bit of advice I read (can't remember where) about persuading people to change is to start with the people who are most open to change.

I used to think that if you wanted to achieve something, you had to convince everyone up front, particularly the most negative folks. Actually, it's much easier to start doing something yourself, and get others who are interested in improving to start doing the same things too. Eventually the negative people realise that it's much easier your way.

Recently, following Joel's advice in painless bug tracking I created a very simple database to track bugs (with a web front end, since that's what I do for a living). At first, only I used it, then the others working on the same project as me. Now there are 5 projects using it, and they all seem to think its really useful. Plus, my boss is now prepared to either develop the idea further or buy a commercial bug tracking system.

So, don't expect everything to happen overnight - be prepared to work at it, and work with others open to change (leave the naysayers to themselves).

Sara Jones
Saturday, December 22, 2001

*  Recent Topics

*  Fog Creek Home