Fewer Mandatory Processes

Expanding on last week’s post about no mandatory code reviews, let me describe another scenario that I frequently run into, which also advocates common sense over mandatory process.

You are making a change or fixing a bug and during that act, you discover something unrelated that is broken, either by testing the product or just looking at the code. You make a quick code change to see if your thinking is correct and it turns out, yes, you just found and resolved an issue unrelated to the original issue you were working on. Now, at this point, you’ve found an issue, root caused it, made a change, and tested it. Most likely, with a minute or two more of investigation, you should be confident that your fix is correct and you can check in the fix to trunk. That’s right, two more minutes and you are done with this bug. Use a meaningful check-in comment to git and go back to concentrating on your original issue. However, most companies employ mandatory processes that all changes must be on a branch, all changes must be tracked in JIRA, and all changes must be code reviewed. Thus, copy your change, create a branch, paste your change, rebuild to verify nothing broke, create a JIRA, describe the issue and resolution, fill in all the mandatory fields (most of which at this point are probably useless since you’ve already resolved the issue), create a code review, go do something else while you wait for all code reviewers to review the changes, come back to this change, merge back to trunk, rebuild to verify nothing broke, and commit. All in all, what could have taken a few minutes, now took an hour in extra process. Ask yourself, was that extra hour really worth the ROI, i.e. to backtrack and fill in the process items for an issue already root caused and fixed? I do not think so. Plus, as mentioned here there are side effects of task switching (slows down progress and creates bugs), or the common case of engineers bypassing readability issues in the code (incorrect comments, fixing poor variable names) because the process is too cumbersome to fix. Also it’s common for engineers to pull in unrelated changes into a single change due to the heavyweight process, though git has a good workaround for this (subversion does not).

Overall, mandatory process has a negative toll on software development. It’s a process-over-people mentality. For reasons already stated, the outcome results in a slowdown of productivity and less readable code. In today’s environment, being slow is death. Companies cannot afford to spend an hour on tasks that can be done in minutes. Like last week’s article, this is a controversial topic and many smart engineers will say my ideas will lead to buggy code, but through experience I know this is not true. With a people-first mentality and properly trained engineers, you can have a more productive team delivering more features and delighting customers.

Leave a Reply

Your email address will not be published. Required fields are marked *