Posted
by
timothy
on Wednesday December 22, 2010 @08:06AM
from the giving-away-all-our-best-tricks dept.

itwbennett writes "In follow-up to last week's controversy over allegations that the FBI installed a number of back doors into the encryption software used by the OpenBSD operating system, OpenBSD lead developer Theo de Raadt said on a discussion list Tuesday, that he believes that a government contracting firm that contributed code to his project 'was probably contracted to write backdoors,' which would grant secret access to encrypted communications. But that he doesn't think that any of this software made it into the OpenBSD code base."

All of these would be sore thumbs in a code review. Getting this into production code would have to rely on your co-contributors being nitwits.

Working at a Very Highly Notable Computer Operating System Producing Company, I was hit by a number of reviews that likely would not have caught any of this code, because no one I worked with cared particularly hard about code-reviews at all. I would constantly get code reviews back that state: "looks good", and then after performing my own code review, I would pull up some crazy stupid easy-to-catch bug that anyone should have seen if they actually looked over my code review.

And when I gave these code reviews to others, what I received back were people being pissed and upset that I would nitpick their code.

As for using totally stupid and inefficient algorithms, I hit across a number of those while working on a bug, and I attempted to refactor them when I could. One of the most egregious issues I dealt with was a config file reader that listed magic constants THREE TIMES throughout the code. Once for a a validity check, the next for a more robust check, and then a huge IF-THEN-ELSE block to define behavior. After refactoring this to use ONE set of definitions for these magic constants, the code was so altered that it could not be backported at all.

I absolutely don't trust code reviews from anyone outside of the open source community anymore. They have their own job to do, and they rarely consider code reviews of someone else's code to be their "job". They view it as being non-productive and non-work... like going to meetings. Volunteers at least take the code-reviews seriously, as it is their own time that they're spending on it.