9

I've been trying to introduce topics such as unit testing, dependency injection, inversion of control, etc... to co-workers. I've given mini lectures, demonstrations, and have suggested these topics during lunch and learns. Reception has generally been positive and people do see value in such topics.

Even though they seem attracted to these topics, adoption has been very low. When I talk to them about it, the answer is generally along the lines of:

I'll try it next time. I just want to get this project out the door.

I have a feeling it's because most of what they have seen are just lecture type demonstrations and they do not have any hands-on experience. What can I do to help nudge them along? I don't want to "force" them into writing code if they don't want to, because it may seem like "homework" and it may leave them with a bad impression.

Our projects generally do not leave time for experimentation, so people tend to shy away from new technologies. This doesn't leave room for developers to try and incorporate new things during the development phase.

Are there any fun or interesting exercises (solo or team) that allows them to have more hands-on experience with these topics? I'm hoping to find something that would peak enough interest so that they are willing to schedule an hour of their day to work on something neat, or peak enough interest so that they'll investigate on their own time.

Improve this question
0

6 Answers 6

Reset to default
14

To "prove" and therefore really implant an idea in someone's head, theory (talking) is never enough.

You have to use those practice in your own code and make them "discover" that it solved problems in a nice way.

That imply that your practices have to be effective and you should make it obvious.

That way, reading your code will inspire them as they will "see it in action".

Don't assume that just telling how it works will be enough.

Improve this answer
1
  • 7
    +1: Do it. Be more productive than others. They'll ask you for advice. Then you can introduce one new idea.
    – S.Lott
    May 12, 2011 at 10:06
7

Speaking from experience, if they are unwilling to apply what you're trying to teach them, it means they don't care about it. You're probably wasting your time by trying to introduce the topics to them, because if they understood the actual benefits of those topics they would want to apply them, not give excuses as to why they can't.

It's just like trying to introduce something better than what's currently being used and getting blank looks or immediate responses why it's not possible to do; it's indicative that the other person doesn't really see it as a benefit (because if they were capable of seeing the benefit, they wouldn't be giving an excuse).

Sad but true. Maybe your situation is different but I've run into this a couple of times in the past and in the end it was painfully obvious that nobody but me was interested in those topics; I ultimately made the decision to leave and try to find co-workers who do care; the kind of people who either don't need me to introduce the topics (because they already know/use them) or who jump on accepting it, instead of saying how they can't do it.

Improve this answer
1
3

I've seen a lot of "best practices" fall out of favour and never get used again. There are many types of projects and such techniques aren't suitable for all projects. Make sure the stuff you're selling really will help.

If you start doing it and people can see you're being extra productive or producing better quality code they will have another look later. Think closely though, will all the extra overhead really help your project? Not every app needs it.

Improve this answer
2

If you can motivate your colleagues to take part, you could organise Coding Dojos. These are programming challenges where the participants deliberately focus on improving practice. Maybe taking part in a test-driven dojo, for example, will lead your colleagues to see the benefits in TDD.

Improve this answer
1
  • I was quite impressed with John Jaggers cyber-dojo.com at this years ACCU conference. In particular, I like the summary screens where you can see different groups approaches and where a good tdd approach will show up visually as a nice red/amber/green/red/amber/green/... traffic light progression.
    – Mark Booth
    May 12, 2011 at 17:19
2

Alternatively, sometimes these things need to be imposed by culture. It strikes me as though the culture in your company is not to need them.

If they become a requirement of project close out (probably a management decision), you will see griping, but at least then some application of said tools and the culture will begin to change.

Improve this answer
0

The best practice is on real production code. Katas are a nice introduction, but in my experience, don't hold the same "Eureka!" Moments as seeing it done for real.

However, you pointed out that timelines "don't allow for experimentation". It's a simple fix really. You're already doing these things that you're trying to teach, so leave an open invitation to pair up with you while you're implementing awesome new feature X. Let them sit at the keyboard and do the typing while you're "back seat driving". This will let them build some muscle memory and confidence.

Good luck in your endeavors.

Improve this answer

Your Answer

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

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