0013: Be Aware of Bikeshedding
Law of triviality is C. Northcote Parkinson's 1957 argument that people within an organization commonly or typically give disproportionate weight to trivial issues.
"The time spent on any item of the agenda will be in inverse proportion to the sum [of money] involved." A reactor is so vastly expensive and complicated that an average person cannot understand it (see ambiguity aversion), so one assumes that those who work on it understand it. On the other hand, everyone can visualize a cheap, simple bicycle shed, so planning one can result in endless discussions because everyone involved wants to add a touch and show personal contribution.
You have most likely experienced during meetings as was pointed out by Parkinson. But this is also happening during code reviews.
Law
The number of comments is in reverse proportion to the number of changed lines.
Easy Pull Requests
You have made some trivial change that is slightly improving the codebase. You were expecting a smooth review process, but it got stuck. Everybody had an idea how it could have been done slightly differently. There was endless discussion and instead of a quick win, it was very painful.
There are several ways how you can try to mitigate this situation. You can either point out, that the time is not effectively used, or you can abandon that change since it is no longer worth the effort.
This could extremely annoying especially when this was your confidence booster.
Complicated Pull Requests
This law also demonstrates in pull requests that are changing something important and complicated. It is hard to gather enough mental energy to correctly review those complicated yet important parts. It is way easier to comment just on formatting, naming, or some other trivial stuff. It does not mean that complicated code could be written terribly. It means that if you have created such a pull request, you should not be surprised, that instead of having discussions about those complicated parts, a lot of discussions could be around those trivial parts.
In these large pull requests, there are portions of the code that are doing the actual work, and the rest of the code is just supporting it. By pointing out those important parts to your reviewers, you can make their life easier. It allows them to focus their energy on these important sections. They use their energy more wisely and you get better feedback. This is a win-win situation for everybody.
Related
Links
| 0012: Have Confidence Boosters In Your Back Pocket | Use Search-oriented Programming: 1000 |