Archive for May, 2020

open source code reviews

Saturday, May 23rd, 2020

I don’t have too many good things to say about open source, but where there is something, I’m happy to admit it.

Lots of good comes from the open source movement. It keeps people off the streets for example.

ha ha.

A lot of great software and tools have come out of the open source effort, but an unbelievably massive amount of lousy software, broken systems and bar-lowering attitudes towards software quality also come from there. I’m not saying open source is completely to blame, but it certainly isn’t helping.

One of the popular arguments for open sourcing software is that it allows interested third parties to code review the software for bugs, security holes and other problems.

I have a lot of things to say about code reviews, but that’s for another book.

I hear the phrase “code review” and I think of all the programming jobs I’ve had where sometimes in a group setting people get to critique your software for various qualities.

My personal view is that code reviews should be for other team members to familiarize themselves with new code you’ve written, and to look for and find bugs. Possibly in trying to understand how new code is supposed to work, and asking questions, a team member might uncover a bug the programmer didn’t spot.

That to me, is the ideal.

But nothing like that actually happens. No two programmers will ever produce the same code to solve the same problem. Everybody has a different style, different handwriting, different experience. The argument over tabs vs spaces is such a common drama that to bring it up is merely to tell a joke so old everybody laughs simply because they know they get to have the tabs vs spaces fight again.

In a business setting, I have found people’s tendencies in code reviews tends to be more about ‘that’s not the way I’d do it’ than ‘tell me if you think this is a bug or not’. I’ve personally seen code reviews that contribute nothing more than “you should change this variable name to that.” I’m trying to imagine any customer that would be willing to pay more for a piece of software because the variable names were changed from one name to another. You could argue that maybe one variable name might be a little more descriptive than another, but not so much that the customer would be willing to pay that much more for it, since now it’s eaten up developer time and increased the cost of producing the product.

This endlessly frustrates me because time that could be spent testing and finding bugs it instead spend dwelling on variable names and source code formatting.

But this is where open source really shines.

It’s hard enough to get anybody to code review anything for free. So if there’s something really worth code reviewing, the reviewer is likely to spend their time looking for bugs or fixing a problem they found, not complaining about formatting or variable names.

This Is Genius. It’s a self solving problem.

Perhaps a lesson can be learned from this.

Software developers get paid to write software, perhaps they should have to volunteer their time to do code reviews.

Now will they volunteer their time? Probably not, but perhaps there is another way to incentivize people to do code reviews for no compensation. Like making it mandatory. Like suffering a penalty if you don’t. Or maybe there’s some backhanded complement kind of thing that can be done that would still drive the need to do code reviews, but only enough to do them the open source/find bugs way, not the corporate america/please-change-your-code-to-suit-my-tastes way. Oh and by the way, after you change code, you’ve invalidated all your testing, so you need to test it all over again, so if you did test anything before, that was a waste of time, because somebody asked you to change a variable name.

I’ll have to think about this some more, but this is clearly something the open source crowd does better than the paid business crowd.