16

Sometimes programmers who work on a project for long time get inflexible, and it becomes difficult to reason with them. Even if we do manage to convince them, they can be unlikely to implement our suggestions.

For instance, I recently joined a project where the build & release process is too complicated and has unnecessary roadblocks.

I suggested that we get rid of some of the development overhead (like filling a few spreadsheets) just by integrating defect management and version control tools (both are IBM-Rational tools so integration can be a very easy one-off effort). Also, if we use tools like Maven & Ant (the project involves Java and some COTS products) build & release can be simplified which should reduce manual errors & intervention.

I managed to convince others and I'm ready to put in the effort to develop a proof of concept. But the ‘Senior’ developer is not willing, possibly because the current process makes him more valuable.

How do we handle this situation without developing friction in the team?

Improve this question
7
  • 2
    I think you need to expand your question with some specific examples. Otherwise, "beat them over the head with a stick", "quit", "write a whitepapers, graphs and powerpoint presentations to communicate your ideas" are the only kinds of answers you can expect...
    – Dean Harding
    Feb 15, 2011 at 10:57
  • "they will be adamant to take suggestion on board" - do you mean "against taking suggestions on board??
    – ozz
    Feb 15, 2011 at 11:28
  • Thanks for the clarification, it makes the question much more valuable and useful, IMO. +1!
    – Dean Harding
    Feb 15, 2011 at 11:46
  • 2
    I have often thought that programming long enough would eventually result in being placed in a mental hospital.
    – Marcie
    Feb 15, 2011 at 19:17
  • 5
    @Marci-I've always believed the field of software development has allowed a percentage of the population from avoiding mental health hospitals. Not that they shouldn't be institutionalized, but that they can hide within some development teams.
    – Jim Rush
    Feb 16, 2011 at 1:05

8 Answers 8

Reset to default
20

You're the new team member and you want to change some fundamental aspects of how the team works. Good luck, I sense a happy team in your future.

Ok, some practical advice:

Prove yourself to the team. You'll need to do this from a technical and reliability perspective. If you want people to follow you, you need to give them a reason to do so.

Understand the history of the methodology. Why does it exist ? What problem was it solving at the time ? Make sure your solution is really a benefit for the team. Maybe your changes are better, but they might not actually solve a problem the team has.

Get to know your roadblocks. Find out the reasons for their resistance and work on those items.

If you want to be an agent of change, learn how to be a successful agent of change. Dozens of books and other sources available to provide you with far more information than you'll get here.

And, yes, I wish you luck. But please, for the sake of your happiness and the happiness of your team, be smart about it. Your desire to make a process change, without investing the energy to craft the right path, could do far more harm than good.

Improve this answer
7
  • +1 for understand the history of the methodology. In many instances there are things which appear irrational that have a highly rational basis. Often the problem is not that the process is wrong, it's that it, and the reasons behind it, have been badly explained because it's all second nature to the existing team who as a result don't get what needs to be explained to a newcomer.
    – Jon Hopkins
    Feb 16, 2011 at 11:08
  • 1
    @Jon Hopkins: Alternately, the process is wrong, but it came about in badly conceived response to real problems. In either case, the newcomer's proposals will be rejected on the entirely legitimate ground that he or she doesn't understand the real problems, and the newcomer's only hope is to understand the history and the problems that led to the current process.
    – David Thornley
    Mar 1, 2011 at 16:20
  • @David - That's certainly possible but our point is the same I think - don't assume, try and understand the detail and the history and then make the call.
    – Jon Hopkins
    Mar 1, 2011 at 16:53
  • 2
    I have yet to see a team "doing it wrong" for any reason other than technical ignorance. This seems yet another case where the "new guy" knows better than everyone else but won't be listened to due to this "cred" issue, so everyone will continue to do things incorrect without ever realizing it.
    – Wayne Molina
    Aug 29, 2011 at 20:03
  • @Wayne: if it were just technical ignorance, simply pointing out the gaps in knowledge would be sufficient. Given that isn't the case, it is far more than ignorance. Many people, by their nature and situation, are resistant to change. As for the reasons, lots. A simple search of "why are people resistant to change" will yield large numbers of useful results.
    – Jim Rush
    Aug 30, 2011 at 12:38
7

I've been in the position you've mentioned. I spent years as a Java developer and eventually went into a job where they were all using Smalltalk. My first reaction was "OMG, they are using this antiquated technology" and I started to try solving Smalltalk specific problems with Java solutions. I can only imagine what a headache I must have been to the other developers and they hated Java with a passion.

It wasn't until I was given a medium sized project to work on while I was mentored by two senior developers over the course of a few months that I started to get the hang of the Smalltalk language and learn to like it. Since leaving that Job and going back to doing Java development, I feel a lot more flexible in that I can take a project and implement it whatever language the company uses. The core thing to get these people to understand is that the language is nothing more than the medium. I've also taken the time to teach myself Lisp and Erlang, but that might not work with everyone.

As a team building strategy, I'd recommend Seven Languages in Seven Weeks to the people you are having trouble with.

I guess it also comes down to how much time these people are willing to invest in becoming more flexible. The trouble with most Universities (at least the ones I've seen) is that they are biased towards a specific language and its students become 'institutionalized' as you mentioned. I think part of your strategy should be to cultivate flexibility in your team. This could be complemented with Domain Driven Development.

(1) Model a domain (A simple one) (2) Implement it using two different languages (i.e Java and Lisp)

Again, this is under the assumption that they are motivated to do the above and are willing to invest their own time to achieve this.

Hope this helps

Improve this answer
2
  • 1
    Please use the book's title in the link instead of "this book". It's one less step for those who readers to decide whether to click or not. Especially those who've previously read it.
    – Huperniketes
    Mar 5, 2011 at 8:28
  • Thanks for the heads up Huperniketes, I was pretty exhuasted when I typed this and didn't go back to sanity check what I've typed.
    – Desolate Planet
    Mar 7, 2011 at 23:58
3

I might be on a totally wrong track here, but it seems to me that same problems are common on a broader scale, and relate to human conservatism. People are often refusing to change the well-known behavior patterns, for reasons that are too numerous to mention.

Being a Russian developer (and therefore seeing less of a rational Western pragmatism), I see practical reasoning to be far less convincing than trying to walk in someone else'e shoes.

In other words, you mentioned that senior programmer values his own position related to the current working scheme. Perhaps you should convince him that the new way of doing things will make his position even more valuable, and there are many ways to do it. For example, you can have him actually pronounce your idea and get credit for it, or you could find a specific spot in the process that he can control exclusively etc.

I believe that being flexible outside apparent advantages of your idea, could be your magic spell here.

Improve this answer
4
  • Credit should be given where credit is due. The senior guy could still take the lead on the implementation of the system but should still give credit to the one that gave the suggestion and worked out most details of the implementation. It's only fair.
    – Htbaa
    Feb 15, 2011 at 15:23
  • That's ethics, which should always be considered. But being a very strategic set of rules, ethics don't necessarily play well for immediate outcome.
    – etranger
    Feb 15, 2011 at 15:30
  • 2
    @Htbaa - actually getting the job done is probably more important making sure that everyone gets due credit. Let's face it: life isn't fair.
    – Stephen C
    Feb 16, 2011 at 3:36
  • I guess you're right Stephen C
    – Htbaa
    Feb 16, 2011 at 21:44
3

I managed to convince others and I'm ready to put in the effort to develop a proof of concept. But the ‘Senior’ developer is not willing, possibly because the current process makes him more valuable.

Rather than casting aspersions on the senior developer's character (bad move), perhaps you should try to understand why he is unenthusiastic:

  • Maybe he thinks you are one of those people who oversells their ideas. Maybe he doubts that you can deliver on them.

  • Maybe he thinks you are exaggerating the problems. (They can't be that bad ...)

  • Maybe he thinks you don't fully grasp the technical risks.

  • Maybe he thinks (knows) there are more important things to do right now.

  • Maybe you just rub him up the wrong way.

My advice would be to prove yourself to him. Like by delivering on the projects that you've been actually given. When he trusts your ability and judgement more, then revisit this issue.

If you do want to pursue the "process improvement" line right now, my advice would be do it slowly, in small steps.

Bear in mind that there undoubtedly is a risk that your proposed changes massively impact on your group's productivity, and even their ability to maintain existing software. If that happens, the person in charge is likely to get the most flak from senior management.

Improve this answer
0
2

Institutionalized about what in particular? Technologies, patterns, practices?

If they've been in the organisation/project for a long time, chances are they're senior developers and have the responsibilty/experience to make those calls, and had experiences in the project rather than just be conditioned like the 5 monkeys experiment.

The solution to the convincing them will depend on what the subject is, since if a pattern/technology is already chosen, there will be a good reason, and there will have to be a better reason to change to justify throwing out work and refamiliarising etc., if so, a solution is for an architect/senior dev organising a meeting to democratically decide the best solution.

Improve this answer
1

If the team really HAS unnecessary road blocks then they will probably be most happy to have you help them fix them. Note however that there might be very good reason for them being there, and you will look stupid if you have to say "oh, well, my fantastic idea doesn't work then" after overselling it to everybody for a long time.

Investigate first, and then come forward. Also note, that being able to SHOW how you suggest it improved is much better than handwaving.

Improve this answer
1

I'm inclined to say that you are the one who is the "Inflexible Programmer". You are new to the project, yet you are insistent that your idea is best and the guy who is leading the project, who has been their longer and knows the system inside and out is just off his rocker.

I'm quite experienced and quite well regarded and frequently get assigned to fix struggling projects as a tiger-team member. Even then I still take the time to learn the hows, whys, dynamics of the team, the project and their practices and not wildly going in and telling them how this and that are wrong. Actually, I never say what they are doing is wrong because that doesn't get the response I want and usually what they are doing is not wrong, it just needs some tweaking.

Each project is unique. Each team is unique. Your solution may be better for you and the developers, but it may not be better for the lead, the customer, the business or the project but since you don't have the experience with the project to know better, you wouldn't know the answer to that.

Improve this answer
0

The best way to get people to do what you want is to make them think everything is their idea. So instead of directly making suggestions, present options. If your ideas are clearly better than the alternatives, give the senior dev a chance to pick them out and make them his or her own. Don't worry about getting credit. The people that matter will know what's going on.

Improve this answer

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.