What to do with star developers who don't document their work?

Question

There is a colleague who seriously knows his stuff, he is one of the brightest I've ever worked with, but he:

• works in his own little area of his home directory rather than in the common CVS repository
• doesn't document his code
• doesn't comment his code, e.g. 3,500 SLOC of C with no comments and no blank lines to break things up
• often overcomplicates things, e.g. uses three shell scripts that call one another to do the work that one simple shell script could do.

Maybe this possibly is one of those people who thinks "if I'm the only person who knows this, they can't get rid of me"?

Any suggestions on what to do?

BTW Management knows about the situation and are trying to change things.

Answer 1

The CVS part is easy - an "accidental" hard drive failure will teach him a lesson for a life (make sure you have a backup though so you won't actually lose code)

Answer 2

That sounds like a tough situation.

Personally, I would let him go. He may be a star developer, but he isn't a team player. And you need to have a cohesive team that can work together if you want to make a good product.

Answer 3

Trying to change things? What do you prefer, a poorly documented working piece of software or a well documented junk? Some people is capable of writing software that requires little to no comments, that is not a reliable indicator of quality.

I'm afraid you're going to lose a good developer.

Answer 4

It's very unlikely that management will get rid of him if he is really bright.

The whole project may be closed, of course, but there will be no use in CVS and documentation then, anyway.

No management will fire a good programmer only to hire a bad one.

Tell him that it will help him to get rid of management whenever he wants to.

What is he wants to change job? He can tell management: "OK, people, everything's just like you asked me: checked in, documented and under you control. I'm done with my part, I pack and leave".

Answer 5

Talk to him?

If he really is a "star developer" he'll take note of what you say.

It may not change him overnight but it might be that he is just completely unaware that other people dont get it quite like he does.

---

Edit:

It's probably a bit late to change now, but more information is needed in working out a solution. It's impossible for anyone here to actually suggest letting the guy go based on these points alone. If you've been telling the guy every day for the last year that he needs to change or he's out of here, then you can let him go. However, I see no evidence of that.

A brilliant developer can be taught to use source control, comment and document. If you spend the effort here then you truly will have a star developer.

Answer 6

Code documentation is over-rated. CVS training is easy.

A good class should reveal its purpose through its methods and properties.

Documenting the model outside of the application is also easier to flow and comprehend.

I would bring it to his attention, if you can't get it resolved looks like you will be losing a star developer.

Edit: Oops - used CSV instead of CVS, to many imports and i use svn heh.

Answer 7

Can the team be successful with out him? If so push the issue and refuse to accept any code that isn’t properly documented or doesn’t meet other standards. Hopefully this will get the point across but it might just make him angry and cause him to quit. If the team can’t be successful with out him then you’re out of luck until you can train a replacement up to his skill level which may not be worth the time and effort.

Answer 8

+1 to ocdecio - if he is a star developer, then his code should be based on such a high-quality design that it documents itself.

Having said that, the frustration could be that although he's excellent in technically-demanding areas which are interesting to him, he doesn't muck-in with the delivery of features - only you will know whether this is a problem for your organisation.

Having a "guru" available can be an absolute life-saver - or at least it used to be, or has StackOverflow made that role redundant?

Answer 9

Failing to document is a (very bad) way to ensure job security.

You can do several things to counter this:

• add documentation as a requirement for the personal performance reviews.
• don't accept software that isn't documented.
• have a word with the developer and find out why he doesn't document.
• Buy a cool documentation tool.

Answer 10

There's more to being a star developer than just being an excellent programmer. If he doesn't have team skills and is purposefully ignoring team standards it needs to be brought up to him. If he refuses to adhere to them after talking with management, perhaps he's not the right fit for your company.

Answer 11

Don't let the code be released until it has passed code review and only allow it to pass if there are enough comments and/or documentation for the code which he has written for the current feature/project.

Edit Bring it up in his appraisal. Documentation / commenting code can be given to him for his "Areas of improvement".

:-)

Answer 12

You could also add automated quality checks that would prevent him checking-in his code until it was sufficiently documented.

That is if you can persuade him to check-in in the first place! (Which is ESSENTIAL, imo)

Answer 13

If he really is that bright and you cannot change his ways, nor do you want to lose him but you still want your code to be documented and commented then my suggestion would be to let a less experienced developer do the documenting and commenting for him. Personally if I were a star developer I would feel prettiy foolish if someone else was made to comment my code and I would start to do it myself eventually. In the meantime while that does not happen the less experienced developer may learn a thing or two.

Answer 14

Is the guy really a rock star? Seriously? Think about it for a second. Is he smart, but doesn't get things done, or is he both smart and able to get things done?

Think about it really hard.

If he really is a rock star, then maybe you shouldn't mess with him. He's producing incredibly awesome things using his own process. Just because there's a different way of doing things that works best for you, doesn't mean that's going to enable him to produce his best work. Instead of trying to get him to bend to your process, which very well could kill all of his awesomeness, you should try and find a way to accommodate the way he works.

If he really is as good as you say, you shouldn't mind doing that. If it isn't worth the effort to do that, then he really isn't that good. In that case, you don't have a rock star, you just have a mediocre programmer that doesn't like to play be the rules. Those guys, you should just get rid of. A temperamental rock star is usually worth the pain, though, because of the quality of what he or she can produce. Those people, you should go to great lengths to keep.

Answer 15

"Hi Star Developer,

just a little informal heads-up to tell you that from next week, we'll be requiring documentation of code, and helpful commenting in the code - it's going to be company policy, and there'll be no exceptions"

From then on, you just deal with that failure the same as you would deal with a failure to turn up on time, a failure to stop goofing off during work, etc. Bottom line is if the boss says document, you document or you're not doing your job properly.

Answer 16

In my opinion somebody doing such stupid things as you have described above can't be a star developer! To me it seems like he intentionally makes things more complicated as they are, so that nobody else than himself can maintain the code. This makes himself more important than he really is! Talk to him. He has to change it! If he doesn't, replace him with a real star-developer!

I promise you, in even half a year he will not know how his own code works! Fire him and you can save a lot of time and money.

Answer 17

Offer bonuses to the other people who do stick to the best practice rules.

Answer 18

Play the bad cop/good cop sketch you have seen from the movies. Let the management be the bad cop and you be the good cop. Let the managament ask for over-kill documentation and per-minute ZIP backups of his work. But you offer him moderate documentation (by doxygen for example) and usual source control check-ins...

Answer 19

Doesn't sound like much of a star programmer to me. All the good programmers know that code formatting and use of source control matters. Sounds like although he makes good progress by himself, he's obstructing the progress of the other team members, which might have a net negative effect on the work getting done. Talk to him, and if he refuses to change his practices, let him go.

Answer 20

You cannot kill people for not doing what you've suggested there. He's just different.

if(developer.IsHuman()) { developer.IsUnique = true; }

I work with folks who write garbage (and call it code). I do that too. Sometimes. But, as you already feel, its annoying not to change bad habits when you know your work affects others. Try to persuade him more.

And, I don't think you can do much in this situation unless you're "The Manager".

Answer 21

There's a lot of folks here on the "no comments, so what?" bandwagon here. Literate code without comments is perfectly possible, but just because someone is smart and doesn't comment doesn't necessarily mean that they are writing literate code.

So let's clarify. You already said he doesn't document his code at all, either in comments or separate documents, and he doesn't use any source control. How about:

• Is his code understandable despite the lack of comments?
• Does your team use any kind of issue tracking (e.g. FogBugz, Bugzilla, etc) which he participates in?
• Is his code under test?
• Is there anyone else on the team who actually is at least somewhat familiar with how his code works?
• Is he willing to at least acknowledge that he could stand to make some changes in the way he works with the rest of the team?

If the answer to all of these questions is "no", you have a big problem. Just being smart doesn't necessarily make someone an asset. Do you have any guarantee that he won't leave your company tomorrow, or get hit by a bus? How screwed would you be if that happened? Is it worth the risk?

Answer 22

Won't? If you've tried everything else, it might be time to remind him who signs his paycheque.

Seriously!

A star developer is no good to you 5 years down the road after he's been hit by a bus and someone else has to work on his code.

Doesn't use CVS? In a company I worked at we made fines for not checking in, three fines and you got fired. Your source code is your business, you lose your source code you lose business. Again, I would remind this guy that his paycheque depends on following company standards.

Answer 23

I think this is pretty typical in any environment. How do you get someone to do what you want? This is exactly what "How to win friends and influence people" is all about. Dale Carnegie was not about manipulation, but managing people.

It sounds to me like he's just inexperienced and needs some experience and guidance.

Do you think you can sit down and talk to him about these issues? Telling someone they're doing something wrong often seems like the wrong thing to do (especially in today's western society where we don't want to hurt other people's feelings) but I think you can get very far by calmly and honestly explaining the issues and talking them through. It helps if the person respects you and your opinion, which is a whole other issue and is talked about in the book mentioned above. Make sure he understands that these are serious issues. Also, that in any future development jobs he'll be expected to do these things too so it's a good idea to practice them now.

I don't think waiting until the next performance review is a good idea. Piling up a bunch of negative feedback and delivering it all at once is just a bad idea and I really disliked it when that was done to me.

Answer 24

1. Get him to use automated execution-verification tools. (See my answer at "How to ask questions to an obsructionist?")

2. If he overcomplicates and does not use SCC, he is not an excellent developer -- these things are important parts of software engineering.

3. In the very unlikely event that he has some irreplaceable brilliance in areas like algorithms, assign him to work in that area, e.g., defining algorithms, and get a real programmer to do the coding.

4. Use static analysis code to understand and clean up his code.

Answer 25

Maybe try using a better version control system than CVS? It might encourage him... :)

Answer 26

This question makes me nervous, because while the person you're describing sounds egregious, I can see a little bit of myself in him.

I think I'm a pretty good team player, and I'm lucky to be on a very good team. However, I do use methods that my colleagues don't understand, though I've tried pretty hard to explain them. There just is a pretty large experience gap, which is no reflection on any of us.

Documentation is a broad and tricky subject. I try to follow the DRY (don't repeat yourself) maxim. Documentation that is separate from the code can amount to repeating yourself, so it is liable to get out of date unless you slow yourself down to keep it up to date. My usual approach is to touch it up afterward.

Often the problem I'm working on is so tricky that I can advance plan and document all I want, but when it comes to the code I often discover that I was wrong and have to re-think it. So the idea that you can document stuff in advance, and just follow that, only works for pretty straightforward problems, it seems to me.

Anyway, I think this is an excellent question, and the answer is not at all simple.

Answer 27

If he is working like this, he is not a star developer - great software developers understand that maintainability is extremely important. You will probably pay dearly for this in the long run, I would be very direct with him about how serious this is and let him go if he can't start to adjust. I have seen this plenty of times before and it is a ticking time bomb.

To be perfectly honest, I have seen plenty of developers like this and, unless they are just out of school, they won't change. I say cut your lossless now, its only going to get harder to fire him as he continues to spew out more unmaintainable code :)

Answer 28

Pair programming. Find hima pair that will "complete" him for requirements you just listed. You will solve a problem will source control, documentation, question every his action, etc. You also train other guy by using first guy strength

Answer 29

From what you describe, this fellow is distinctly not a star developer. Programming is a team sport, and those who do not play well with others do not add much value to a project.

Personally, I might not remember code I wrote 6 months or more ago, and very much value a history of the changes in some sort of Source Control.

If you had regular code reviews with this guy I think you would see that he's not as stellar of a developer as you think he is.

Answer 30

I agree with most people on this thread. One way to put him on the hot spot is to have Team Code Reviews.

For the first code review meeting choose code from a team member that is open and will accept the recommendations. The "star" developer will have the chance to see how the code review works and then you can schedule his code to be reviewed next. Give him some time to prepare for the next meeting and by then he should be at least commenting his code.

The intention of code reviews is not to put shame on people but rather to collaboratively identify issues and places for improvement, but it will be a good way to put the star developer on the hot seat.

Answer 31

In my opinion, you need to drop this guy. It sounds like his code is unreadable and he is definitely not a team, nor a safe, player.

It is also a very bad practice to allow someone to see themselves as indispensible. If you let him keep this up, his practices will get worse, not better. When he leaves, for everyone does, you will be left with an enormous headache of tangled code. You need to cut your losses now if he will not shape up.

Finally, keeping this developer without reigning him in sets a poor example from junior developers. If you force them to work correctly, you risk resentment from the "why him and not me" crowd. If you don't, you get a bunch of hacks who work like your "star."

In short, unless he shapes up very, very quickly, it's time to drop him, for the health and sanity of your entire development staff.

Answer 32

May I recommend Manager Tools. We want a particular behavior. Behavior can be measured, goals set, and changed. Tools you can use everywhere.

Answer 33

We had a similar problem when I started my current job a little over 3 years ago, our lead developer was a cowboy. He was really smart but very erratic, some of his stuff was very well documented, but so overly complicated it was imposable to maintain, or code first and figure out what he was building later, he would throw out code to see what would stick.

He left about 2 1/2 years ago, and it's still haunting us when we find some of his old code, and in his defense that's how the development shop here was run back then, in the last 3 years I have been on a crusade to change that mentality.

When you become a star developer it stops being so much about how well you know the system, code, framework, architecture, etc. and more about

1. Writing elegant, maintainable, flexible, readable code
2. Working with the rest of the team: using source control, leading by example, etc.
3. Documenting what each method, class, object, etc is doing
4. Researching new and better ways to do things for yourself, and your team

if your not following all four of these at some level your not a star developer, more so if you refuse to try/learn to use them then it's time that that should find other employment opportunities one way or another, I hear starving artist is popular with this time of person (the whole misunderstand genius thing)

Answer 34

While individual achievement may be important and useful in some cases, it is team work and good collaboration among all players and stakeholders what will ultimately make most projects successful.

Documentation is part of the collaboration process. If your "star developer" is not putting his weight on this topic then inform him and put it in his review.

Document the problems that your "star developer" has caused due to his lack of documentation. Make a case of this issue to upper management with examples of these issues and ensure that he understands the consequences. If he continues to fail in this aspect then treat it like any other failure... termination being the last course.

Above all, make him aware of the problem and give him a chance to improve. if you see no improvement over an agreed period of time, then he is not willing to imporve himeself, and the team. You know what has to be done!

Good Luck! Andres

Answer 35

You might be focusing on the wrong area here, you are being provided with an opportunity to see some weaknesses in your process.

• works in his own little area of his home directory rather than in the common CVS repository

A simple chat will probably suffice here, the benefits of version control speak for themselves and any "bright" person would likely be enthusiastic about those benefits. However it may also be a good chance to look into alternative version control systems that allow greater ease of use and flexibility (take a look at bzr and git). Better yet, get him involved in the selection process, if he really is a "star" he'll probably have good input and be more vested in its use.

• doesn't document his code

It doesn't sound like documentation is part of your process. People are going to resist having to do extra work and if there isn't a defined process then you're talking about a lot of extra work. Is documentation really needed? If so, is there a process defined for creating it? should you have someone entirely dedicated to it? Should you at least have a tool to facilitate it (maybe something as simple as mediawiki)?

• doesn't comment his code, e.g. 3,500 SLOC of C with no comments and no blank lines to beak things up

Three words: peer code review. Outside of obvious error-catching benefits, this also can provide some peer pressure, which is a strong force and can be a good thing. Wanting to be perceived well by your peers self-generates ownership and quality.

• often overcomplicates things, e.g. uses three shell scripts that call one another to do the work that one simple shell script could do.

Again, peer code review. You mention that management knows about this programmer's deficiencies. Does he? It's rather difficult for people to change and improve if they don't recognize the problems with the way they're doing things.

And, perhaps best of all, by coming up with plans to improve your development process (which will likely improve not only your "star" but everyone else on the team) you can probably earn some gold stars for yourself from management.

Answer 36

often overcomplicates things, e.g. uses three shell scripts that call one another to do the work that one simple shell script could do.

This doesn't sound like he's exactly writing literate self documenting code to me, rather the opposite. Seems like his choice of overly complicated solutions creates an unusually large need for documentation, and also making the lack of documentation a much more severe problem.

Answer 37

3500 LOC with no comments?! no SCM?! Oh man! I have an idea.. better than 1000 words on it..

Answer 38

I agree on the comments that say that he can't be a rock star programmer since he is not documenting his work and he's not producing high quality work either.

Answer 39

I think that team members should understand each other's responsibilities i.e. it is DBA responsibility to work with DB, you don't ask QA to apply DB patch. And DBA can not refuse to do it, because it is his/her responsibility. It should be clear to everybody that one of team member's responsibilities is writing code that can be easily understood by other team members. And I think from that perspective it should be resolved from the person he reports to.

If your DBA does not work with DB, and instead does something else, like building UI, he/she does not do his job. Same with your colleague - if he produces code that can not be understood by other team members - he does not do his job.

Writing code that can not be understood by his colleagues should not be considered as completing the task. Writing the code that is not in CVS so can not be reviewed by other team members until it is too late - also should not be considered as completing the task. Writing 3 scripts instead of 1 should be considered a waste of time.

If management can not understand that and still consider him rock star programmer - consider changing the management.

I would also emphasize that goal is not writing comments itself. It should be understandable code, easy to maintain. I personally consider comments as last resort to make my code understandable - I prefer clean design and naming first.

Answer 40

Give his code back to him and tell him to fix it or he's fired.

Answer 41

Fail code review.

Answer 42

Sounds like a star programmer who's bored of his job and is over complicating things to make it more of a challenge. He'll find something better soon enough.

Answer 43

Here's another tact you could try, in addition to many of the other suggestions:

It seems you're pre-disposed to think that your developer's behavior and methods are bad, for whatever reason. Assuming you have discussed them with him and he has not provided justification to your satisfaction (or willingness to change), I'd say you have two obvious choices: get rid of him, or live with it. I would suggest that, in this case, you be very up-front with your demands of how he write his code, and let him choose to take it or leave it.

As an example, I had a previous employer who (after a management shakeup) decided that the developers were no longer allowed to use 'assert' in code, because they considered it unnecessary clutter and not consistent with the existing style of now "in charge" group (who wrote very direct low-level C style code with no assertions or defensive programming techniques). The management and I had a direct discussion, they told me I needed to adapt to their style or leave, and I decided to leave. Overall, I think it worked out best for both parties.

Not everybody is going to have the same opinions on coding, code guidelines, or development processes, and at the end of the day, the person paying the money makes the rules (balanced against the need to actually produce things). The more up-front you are about what you require, the less resentful developers will be.

Answer 44

Why document? We all know noone ever reads that later. Just write good comments.

Answer 45

Could be the reason he "knows his stuff" is because it's exactly that - "his stuff". The best code is code other programmers can understand and modify with confidence.

Impressive coders who don't mentor others and write code only they understand are IMHO a liability - especially after they've answered enough questions so you know how to rewrite their code and can send them along to help someone else.