Developer thinks they do not have to follow standard development process [duplicate]

Question

This question already has answers here:

How do you disarm a cowboy coder? [closed] (5 answers)

Is cowboy programming a senior approach? [duplicate]

Closed 7 years ago.

How do you deal with a senior developer who does not think that the company standard way of developing software applies to them ?

For instance:

1. Will ask other developers to do work by email, rather than assign bugs to them.
2. Will keep copies of documentation and code in their own local area, rather than keeping them in the common area under source control. (and overwrite others changes with theirs)

NOTE: This has been flagged to QA people before.

Answer 1

I document their activities, give them multiple written warnings, work with HR to create and implement an improvement plan, then I fire them.

edit

Since you're not the manager, the best you can do is document what you see (stick to facts) and forward to your manager once in a while. If any of your peers complain to you about this person, encourage them to also document & forward to the boss.

Having a stack of documented events from multiple peers is very helpful to the manager when it's time to take action.

Answer 2

Obviously, firing them or reporting them to management is an option; whether or not it would be my first choice as an option would depend on whether or not they're also a good developer.

It seems wrong-headed to send a very smart person packing just because they don't follow the process. Especially if you don't fully understand why they don't follow the process. I would suggest that instead of simply labeling this person as a renegade and looking for ways to deal with the person, you address each of the problematic behaviours one by one and look for ways to deal with those specific behaviours.

For instance:

• Not committing things to source control is infuriating (as a lead, I've occasionally had to politely grill others about this) but sometimes it's hard to find alternatives, especially if you're using old-school centralized VCS where you only get one chance to fix merge conflicts and commit.

  When dealing with TFS or even SVN, before the git-tfs or git-svn plugins were stable, I would frequently have to make backups of my working copy just in case I messed up a merge. In companies where merge conflicts are difficult to resolve or broken builds aren't handled properly, delayed commits or no commits can be a defensive behaviour that points to higher-level organizational problems that need to be resolved.

  Not saying any of that applies to you or your teammate or your organization, the point is we don't know, and I assume you don't know either, otherwise you would probably have included that information in your question. (right?)

• For problem #1 (using email for work assignment), the solution is blindingly obvious: Ignore them. I think the vast majority of developers have had to deal with this problem at one point, although the more common incarnation of the problem is business users making requests by email, as opposed to other developers/managers.

  It's basically the same situation, though. You ignore the email requests, and if pressed, you politely explain that your email comes in too fast and too frequently to be able to keep track of any issues or requests buried in there, and that you need it in the bug database in order to track your own time. Mention this to the Project Manager, assuming you have one; they will definitely take your side on it.

  I've found myself at the business end of this, too, when dealing with sysadmins; sometimes there's a blurry line between just asking a question on IM and requesting an investigation of some issue, and I'll get told to submit a ticket by emailing their tracking address. It's a minor inconvenience but it's really no big deal, I understand how their time is both highly compressed and under intense scrutiny, and they can't afford to be doing random stuff for random people without a priority attached.

In most cases, if there is a good reason for a process to exist, then it should be a simple matter for you to either register a formal complaint, or to simply follow the correct process yourself and let others deal with the consequences of not following it.

But, as I mentioned before, make sure that what you're complaining about is the specific process not being followed, don't word it as a general complaint about the person otherwise you'll almost certainly come out looking like the bad guy.

Answer 3

To encourage the usage of a bug tracking system instead of e-mails, you can use the same technique I've used with my customers. Create an automated e-mail explaining how to submit a bug or request a feature on a bug tracking system. Send this automated e-mail each time you receive a bug/feature request by mail.

Few days later, the person would be so annoyed that either he will confront you (beware of angry people), or start using the bug tracking system.

Similarly, ignore documents which are not stored in the official repository. If the person asks you why haven't you followed a specific document, ask which one, and tell that you never read it, since it's not in the repository.