LCE2011: Kernel developer panel [LWN.net]

LCE2011: Kernel developer panel

Posted Oct 27, 2011 9:25 UTC (Thu) by dgm (subscriber, #49227)
Parent article: LCE2011: Kernel developer panel

"The kernel has always been complicated, Torvalds said, but it is not getting less complicated over time. There is a balancing act between the right level of complexity to do the job right and over-complicating things.

Cox believes that the complexity problem is self-correcting for the most part. Once a subsystem becomes too complicated, it eventually gets replaced with something simpler. But code quality is a problem our industry has faced for sixty years."

I was going to write about how both problems are similar, but I just realized that simplicity is just a subset of the fuzzy group of properties we call "quality". It has also the nice property of being well defined (mathematically) and directly measurable.Quality on the other hand is a broad and probably subjective concept. The trouble with complexity is that we actually need some of it if we want to do anything non trivial, the trick being finding just how much is enough.

Alan's comment on complexity does easily apply to quality in general. Any part of the code bad enough will eventually be rewritten.

(Log in to post comments)

LCE2011: Kernel developer panel

Posted Oct 27, 2011 19:05 UTC (Thu) by iabervon (subscriber, #722) [Link]

I think there are some aspects of quality which are not covered by simplicity. For example, how large a typo do you have to make to change correct code to incorrect code, and how hard is it to notice that typo? (Is your style for an assignment and an equality test in a conditional very close?) How hard is it to prepare a patch which does not affect any lines that it doesn't need to affect? (Do you have to add a comma to the line containing a list element you are not changing? Do you have to reproduce hidden whitespace in lines you changed during development but put back?) Do your function names suggest the right effects and not the wrong ones? Are your function behaviors systematic? How closely are different stylistic conventions mixed?

I think a lot of the quality question comes down to how predictable the code is from its purpose and the rest of the code in the system. Complexity of the design limits this, and you can think of it as less entropy and therefore less complexity, but the term "complexity" doesn't usually make people wonder how many bits of entropy there are in the whitespace in the codebase.