<a href=”http://lkml.indiana.edu/hypermail/linux/kernel/9905.0/0632.html”This quote by Linus Torvalds</a> has stuck with me since I first read it back in 1999
I generally have a problem with your patches: a lot of them are really
good. But at the same time a lot of them are changing things because
you're in "random walk" mode, and you just walk over the code without
really thinking about them. In the end, you then have a huge patch, and
nobody really knows which part of your patch is really the worthwhile part.
Which is then why it takes so long for some of your _real_ fixes to
get into a stable kernel..
It’s not the only occurrence of him talking about software developers using the’random walk’ methodology for code improvement - sometimes he is occasionally less polite.
As a developer, if you notice something else is broken or needs improvement, fix each problem in a separate and logically internally-consistent change that makes sense to the reader and the end user. Doing things this way means less cognitive load for everyone involved, as they can weigh up each part of your change with a consistent end-goal in mind, and build a clear mental model of your change without irrelevant detours.
This method also nicely matches one of the more general rules of debugging: change one thing at a time. If you change 10 different and unrelated things at once and the system breaks, it’s often much more difficult to determine why the problem occurred.
Following this method also means that it’s much easier to revert a single change that’s gone wrong, without the side effect of bug-free changes disappearing, simply because they were included in the same patch set.
So: fix one thing at a time, and fix it right.
