Question

G’day,

This is related to my question on star developers and to this question regarding telling someone that they’re writing bad code but I’m looking at a situation that is more specific.

That is, how do I tell a “star” that their changes to a program that I’d written are poorly made and inconsistently implemented without just sounding like I’m annoyed at someone “playing with my stuff”?

The new functionality added was deliberatly left out of the original version of this shell script to keep the it as simple as possible until we got an idea of the errors we were going to see with the system under load.

Basically, I’d argued that to try and second guess all error situations was impossible and in fact could leave us heading down a completely wrong path after having done a lot of work.

After seeing what needed to be added, someone dived in and made the additions but unfortunately:

1. the logic is not consistent
2. the variable names no longer describe the data they contain
3. there are almost no comments at all
4. the way in which the variables are used is not easy to follow and massively decreases readability and hence maintainability.

I always try and approach coding from the Damien Conway point of view “Always code as if your system is going to be maintained by a psychopath who knows where you live.” That is, I try to make it easy for follow and not as an advertisement for my own brilliance. “What does this piece of code do?” exercises are fun and are best left to obfuscation contests IMHO.

Any suggestions greatly received.

cheers,

Answer 1

I would just be honest about it. You don’t necessarily need to point every little detail that’s wrong, but it’s worth having a couple of examples of any general points you’re going to make. You might want to make notes about other examples that you don’t call out in the first brief feedback, in case they challenge your reasoning.

Try to make sure that the feedback is entirely about the code rather than the person. For example:

Good: The argument validation in foo() seems inconsistent with that in bar(). In foo(), a NullPointerException is thrown if the caller passes in null, whereas bar() throws IllegalArgumentException.

Bad: Your argument validation is all over the place. You throw NullPointerException in foo() but IllegalArgumentException in bar(). Please try to be consistent.

Even with a “please,” the second form is talking about the developer rather than the code.

Of course in many cases you don’t need to worry about being so careful, but if you think they’re going to be very sensitive about it, it’s worth making the effort. (Read what you’ve written carefully, if it’s written feedback: I accidentally included a “you” in the first version to start with 🙂

I’ve found that most developers (superstar or not) are pretty reasonable about accepting, “No, I didn’t implement that feature because it has problem X.” It’s possible that I’ve been lucky though.