Code Quality In Open and Closed Source Kernels

Diomidis Spinellis writes "Earlier today I presented at the 30th International Conference on Software Engineering a research paper comparing the code quality of Linux, Windows (its research kernel distribution), OpenSolaris, and FreeBSD. For the comparison I parsed multiple configurations of these systems (more than ten million lines) and stored the results in four databases, where I could run SQL queries on them. This amounted to 8GB of data, 160 million records. (I've made the databases and the SQL queries available online.) The areas I examined were file organization, code structure, code style, preprocessing, and data organization. To my surprise there was no clear winner or loser, but there were interesting differences in specific areas. As the summary concludes: '..the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.'"

Comments

Is it just me?

[Abreu]

Or the summary is completely incomprehensible?

Of course, I could try to RTFA, but hey, this is Slashdot, after all...

Re:Is it just me?

[Anonymous Coward]

That is if you can figure out which of the 12 links are the actual FA and which are supporting material.

Re:Is it just me?

[Bazman]

Well, it's not just you, but probably millions like you. Plenty of the summary is comprehensible, but I get the fear that it's really just a slashvertisement for his book (third link in summary).

Re:Is it just me?

[raddan]

It's not a very good summary, but the paper is well-written, which is interesting considering that the author is the one who submitted the summary to Slashdot. I suspect that he assumes we have more familiarity with the subject than we actually do.

Re:Is it just me?

[stavrosg]

TFA is the second link, but yes, the summary does not do much to help you figure it out.

Re:Is it just me?

[Diomidis Spinellis]

I didn't write the last part when I submitted the story, and, yes, the summary given here is comprehensible, because it appears out of context. What the sentence '..the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.' means is that when you build something complex and demanding, say a dam or an operating system kernel, the end result will have a specific level of quality, no matter how you build it. For this reason the differences in the software built with a tightly-controlled proprietary software process and that built using an open-source process are not that big.

Re:Is it just me?

[Diomidis Spinellis]

It's not a very good summary, but the paper is well-written, which is interesting considering that the author is the one who submitted the summary to Slashdot. I suspect that he assumes we have more familiarity with the subject than we actually do. In my submission I did not include the last sentence with the "summary", which, I agree, is completely incomprehensible in the form it appears.

Re:Is it just me?

[tcopeland]

> the paper is well-written

Yup, and the author of the paper is Diomidis Spinellis, who wrote the excellent book Code Reading. This is a great study of code analysis and familiarization techniques. He also wrote a fine article on C preprocessors... in Dr. Dobb's Journal, I think.

Re:Is it just me?

[legutierr]

How useful is it to write something about computers that needs to be translated for the slashdot audience? Jargon is a great way to provide specialized information to insiders quickly and efficiently, but this is slashdot. If slashdot readers need for you to restate your description of a problem or observation related to the Linux kernel (even if that description is taken out of context), could it be that the paper could be written in a more open manner? The quote you provided from your paper seems to speak to a narrow audience; how narrow must your audience be, however, if it excludes a good portion of slashdot's readers?

If I seem overly critical, I do not mean to, it is only that I hate to see good, useful research made less accessible to non-academics by the use of academic language.

Re:Is it just me?

[Diomidis Spinellis]

This is a very good point...

Re:Is it just me?

[utopianfiat]

Well, it's the second link. At any rate, the highlights of the data are that for the most part the kernels are tied in the important material, except:

% style conforming lines: FBSD:77.27 LIN:77.96 SOLARIS:84.32 WIN:33.30
% style conforming typedef identifiers: FBSD:57.1 LIN:59.2 SOLARIS:86.9 WIN:100.0
% style conforming aggregate tags: FBSD:0.0 LIN:0.0 SOLARIS:20.7 WIN:98.2

(I'm far too lazy to clean up the rest)

% of variable declarations with global scope 0.36 0.19 1.02 1.86
% of variable operands with global scope 3.3 0.5 1.3 2.3
% of identifiers with wrongly global scope 0.28 0.17 1.51 3.53

Re:Is it just me?

[Diomidis Spinellis]

The preprocessor algorithm I described in the Dr. Dobb's article is the one I used for parsing the code of this study. A strange preprocessor construct in the Linux kernel caused the macro-expansion algorithm I used previously to fail.

Re:Is it just me?

[CherniyVolk]

... means is that when you build something complex and demanding, say a dam or an operating system kernel, the end result will have a specific level of quality, no matter how you build it.

First, Mr. Spinellis I found the report to be rather intriguing and captivating. I much respect the work put into it, and I think it'll prove valuable resource for study or reference.

With that said, the above quote struck a chord with me.

Let's take fire control systems for weapons of mass destruction. Without going into detail, the basic fact is that if a thermo-nuclear warhead is launched from Russia, France, UK, Isreal, US or any other country, it was and will be a deliberate act. The systems are far too complex and far too reliable for error or mistake. In other words, regardless of political position, no ruling body is going to ignore the possibility of an oopsie launch.

So, I do understand, that certain objectives, though may be approached and implemented vastly differently, will have strong similarities in the end result and with how it was successfully applied.

My problem is with this. What your saying is that there is no quality difference between Windows and Linux, and this is the discordant chord struck.

I can not extrapolate the agreeable portions of your thought to the seemingly obvious short comings of the Windows operating system. On any facet, whether it is security, stability, functionality or reliability. Windows is, far behind on all fronts.... aside from secrecy from a Microsoft point of view.

I once told my boss, who well understood, that he would never get the quality of code from me in the workplace as I might submit for the Open Source realm. It's just painfully obvious, that I will, at some point, hack an improper solution together for his deadline. And the nature of business, after the product is built, no one wants to change it unless they have to. So, while the economics all come into play here, why Microsoft might choose to fix one bug versus the other, the fact is in Open Source a bug will be fix on merit of a fix being available and acknowledgment that the bug is in fact a bug. Regardless if it's economically sound or feasible to fix the bug, in Open Source, it will be fixed.

While the end results that you present are interesting, I can not accept the proposition that the Windows kernel is too similar in quality. All one has to do is actually use the blasted thing, and no amount of numbers can be that convincing to ignore all the pitfalls well perceived from actually using the dreadful software.

I think you have overlooked overwhelming variables that directly effect the quality of software. Or, perhaps, the WRK has been a meticulous focus at Microsoft before it's release... this is likely possible, as it's WIDELY known, from nearly ALL examples of closed source proprietary software being released to the Open Source, that it takes years just to clean up and prepare for the ultra high standards of the OS community.

Re:Is it just me?

[Diomidis Spinellis]

Please let me clarify here:

I can not extrapolate the agreeable portions of your thought to the seemingly obvious short comings of the Windows operating system. On any facet, whether it is security, stability, functionality or reliability. Windows is, far behind on all fronts.... aside from secrecy from a Microsoft point of view. I'm not claiming anything regarding these external quality attributes of Windows, the metrics I collected just show that there are no vast differences in the code's quality.

Or, perhaps, the WRK has been a meticulous focus at Microsoft before it's release... this is likely possible, as it's WIDELY known, from nearly ALL examples of closed source proprietary software being released to the Open Source, that it takes years just to clean up and prepare for the ultra high standards of the OS community. This is entirely possible. In fact, a README file in the distribution states:

The primary modifications to WRK from the released kernel are related to cleanup and removal of server support, such as code related to the Intel IA64.

Re:Is it just me?

[Allador]

I think you're vastly overestimating the overall knowledge, experience, and education in this context of the /. readership.

Only a small portion of the /. readers are programmers/developers (or in an academic speciality in this field).

Even amongst that population, only a small percentage are qualified in large operating systems development.

Similarly, a small percentage of the programmer subpopulation of /. will be familiar with the various theory, metrics and approaches to measuring and analyzing code quality.

The target population of the paper are people who fit into all three of these groups. Thats not very many people.

I've been doing software development for a living for almost 2 decades, but arent familiar with many of the metrics and approaches used to analyze the source code (of course some, like cyclomatic complexity, line lengths, operands per line, etc etc I am familiar with).

This is incredibly narrowly focused stuff, even for /.

It's obvious

[Number6.2]

That you have neither capitalized on your shared synergies, nor have you recovered your cherished paradigms.

Oh. Wait. This is about propeller-head stuff rather than management stuff. Lemme get my "Handbook of postmodern buzz words"...

Not that surprising

[abigor]

Final line in the paper: "Therefore, the most we can read from the overall balance of marks is that open source development approaches do not produce software of markedly higher quality than proprietary software development."

Interesting, but not shocking for those who have worked with disciplined commercial teams. I wonder what the results would be in less critical areas than the kernel, say certain types of applications.

Re:Not that surprising

[ivan256]

It's obvious what the results would be.

Half completed, unpolished commercial software usually stays unreleased and safe from this sort of scrutiny. However many of the same types of projects get left out in the open and easily visible to everybody when developed as open source. The low code quality of these projects would drag down the average for open source projects as a whole.

On the lighter side, you could say that you'd only consider software that was "out of beta" or version 1.0 or greater, but that would leave out most open source projects and commercial "Web 2.0" products....

Re:Not that surprising

[indifferent children]

So open source software is not of 'markedly' higher quality. If it is of even 'slightly' higher quality, or 'exactly the same quality' as closed source software, then the fact that it costs less, and gives users freedoms that they don't have with closed source software, means that closed source is doomed.

Re:Not that surprising

[abigor]

Well, not necessarily. Perhaps for certain types of commodity applications, like office suites, but even then, it's tough to say. That's why I was interested in the comparison. Your assertion is certainly not true for games, for example.

Generally speaking, commercial desktop apps are still way ahead of their open counterparts, with the exception of code development tools and anything that directly implements a standard (browsers, mail clients, etc.)

One reason for this is that code quality as measured in this study may not directly relate to application quality as measured by the typical user. Photoshop is "good" not least because of its well-understood interface and the fact that everyone uses it, regardless of how admirable the code is.

Re:Not that surprising

[FishWithAHammer]

Generally speaking, commercial desktop apps are still way ahead of their open counterparts, with the exception of code development tools and anything that directly implements a standard (browsers, mail clients, etc.) Code development tools? VS says hi. (And somebody is now going to leap in and say that that monstrosity Eclipse is somehow "better" than VS...this will be amusing.)

Re:Not that surprising

[Mongoose Disciple]

So open source software is not of 'markedly' higher quality. If it is of even 'slightly' higher quality, or 'exactly the same quality' as closed source software, then the fact that it costs less, and gives users freedoms that they don't have with closed source software, means that closed source is doomed.

The problem with your conclusion is that it assumes that code quality as measured in this sort of way is the only or even the most important thing.

It's like buying clothes. Sure, the quality of the clothes you're buying does matter some in making your choice. So does price (which you mention above.) But, what the clothes look/feel like is also often important, and something like whether or not they actually fit you can trump all of those concerns.

In general I would say the open source world (as represented by the best known / flagship projects) produces higher quality code. It's better at finding and fixing bugs. It's often better at fixing inefficient algorithms and the like.

What it's generally [i]not[/i] as good at are higher-level or market-driven concerns, like if a UI is just bad and needs to be replaced whole-cloth, or if key feature that a developer would never use but that most users will want is present, or if documentation is provided or of sufficient quality.

As long as that's true, both open and closed source projects will continue to exist. They're best at different kinds of things, and I would argue they exist in a kind of symbiosis.

Re:Not that surprising

[samkass]

Yes, but there is absolutely no evidence that open source is any better in this respect than commercial software (in fact the actual evidence points to it being little different in this respect). And when it DOES crash, a 1-800 number is often better than a pile of badly commented code.

It will, in the end, come down to a value proposition. The value proposition of freedom to modify code is very hard to quantify, so that will probably factor into the eventual success of open source not at all. The actual quality, usability, documentation, trainability, ease of install, compatibility with existing infrastructure (usually Microsoft), etc., will probably be the deciding factors, and I don't see open source having a clear-cut advantage in those metrics.

Re:Not that surprising

[raddan]

But the author also points out that his measure of "quality" is limited. From the paper:

Other methodological limitations of this study are the small number of (admittedly large and important) systems studied, the language specificity of the employed metrics, and the coverage of only maintainability and portability from the space of all software quality attributes. This last limitation means that the study fails to take into account the large and important set of quality attributes that are typically determined at runtime: functionality, reliability, usability, and efficiency. However, these missing attributes are affected by configuration, tuning, and workload selection. Studying them would introduce additional subjective criteria. The controversy surrounding studies comparing competing operating systems in areas like security or performance demonstrates the difficulty of such approaches. From the end-user perspective functionality, reliability, usability, and efficiency are pretty much the entire thing. Most users couldn't care less that a piece of software is hard to maintain as long as it does what he wants reliably, consistently, and with a minimal amount of cognitive load. So this paper is aimed more at applying traditional software engineering metrics to four pieces of real-world software. The outcome *should* show little difference, since all four of these pieces of software are used in mission-critical applications. It would be surprising if one or more of them were not at all in the same ballpark, but it is nonetheless interesting that very different software development styles basically create products with roughly the same mesaures, e.g., modularity.

Re:Not that surprising

[Diomidis Spinellis]

I don't think that my results can support us in making arguments regarding 'slightly' higher quality, or 'exactly the same quality'. My figures are based on possibly interdependent, unweighted, and unvalidated metrics. Therefore they only allow us to make conclusions involving large differences.

Re:Not that surprising

[phantomfive]

As I take a break from VS to enjoy some time on slashdot, I have no understanding of why people think VS is so amazing.

Is it because of intellisense? That's kind of nice, especially when your code is so disorganized that you don't remember where stuff is defined. Or if you can't open stuff up in two different windows to see where it is defined, like VS prevents you from doing (yeah, you sort of can, but it's stuck in the main VS window).

Is it because of the debugger? Sure, the debugger is nice, and I like it, but it only helps get rid of the easy bugs. The bugs that really eat your development time are the ones that only manifest themselves after the program has been running for a few hours/days, and usually a debugger doesn't help much with that. Besides, every other IDE comes with a debugger, even GDB works fine if you can handle arcane keystroke combinations.

And on top of it, Solutions and projects in VS are horrible. Why does VS try to save the solution every time I quit? Makefiles have some awful syntax, but at least when they change, I know it's because of what I've done, and I know how to fix it.

That said, I don't consider VS to be a bad IDE, it is reasonably decent. I just don't understand the logic of these guys who think that VS is the greatest IDE ever. It's a question, not a flame.

Re:Not that surprising

[CrazedWalrus]

Um, yes.

You seem to forget that the Linux forums are generally stellar for resolving HOW-TO questions. Additionally, there are FAQs and instructional blog posts that are readily accessible through Google. In other words, "Toggle That Doohicky" is easily obtained in the FOSS environment as well, and can be done WITHOUT sitting on hold and taking your chances with the quality of the rep who answers.

Additionally, if the source were available, features you want could be added, someone ambitious enough could actually investigate *why* the damn thing works the way it does, and it'd probably have working Linux and Mac versions by now.

Re:Not that surprising

[xenocide2]

On the lighter side, you could say that you'd only consider software that was "out of beta" or version 1.0 or greater, but that would leave out most open source projects and commercial "Web 2.0" products....

Then restrain yourself to "what Fedora ships" or "what Canonical supports in main". These are the presumably viable software products with a living upstream.

But you missed an interesting problem: failed commercial programs sometimes convert into open source projects. Its not clear to me whether this is a positive or negative effect. Are there more s out there or Blenders? Is the OpenOffice.org software good or bad?

No-one has ever claimed

[wellingtonsteve]

..that Open Source code is of quality, but at least the point of things like the GPL is that you have the power to change that, and improve that code..

Re:No-one has ever claimed

[KutuluWare]

You haven't been paying attention to many Open Source proponents if you haven't ever seen them claim that Open Source code is of vastly superior quality than proprietary. Hell, ESR's claim to fame is a whole paper he wrote on that exact topic. For example, the OSI itself puts this claim at the very top of their advocacy document on selling OSS to your management:

The foundation of the business case for open-source is high reliability. Open-source software is peer-reviewed software; it is more reliable than closed, proprietary software. Mature open-source code is as bulletproof as software ever gets.
  Open Source Case for Business There is a pretty clear divide in the F/OSS community between the OSI-side-people, who view Open Source as a development model that leads to better software with fewer bugs and quicker turnaround; and the FSF-side-people who think of Free Software as a moral imperative that leads to more freedom in addition to better software with fewer bugs and quicker turnaround.

Having worked heavily in both areas of software development, I think this particular article's conclusion was obvious: code quality depends on the people who wrote it, not the process the used to license it. But only people who have done extensive proprietary and open-source development could really see that first-hand, and our opinions are automatically dismissed as being pro-Microsoft shills. Thus, I predict this paper will be roasted over an open flame, crushed into a tiny ball, soaked in gasoline, lit on fire, and ejected into deep space by the most devoted open source proponents in both camps.

CScout Compilation

[allenw]

"The OpenSolaris kernel was a welcomed surprise: it was the only body of source code that did not require any extensions to CScout in order to compile."

Given that the Solaris kernel has been compiled by two very different compilers (Sun Studio, of course, and gcc), it isn't that surprising. Because of the compiler issues, it is likely the most ANSI compliant of the bunch.

statistical wash-out?

[davejenkins]

If I am understanding correctly, you were looking for 'winners' and 'losers' (weasel words in and of themselves, but anyway...) in terms of 'quality' (another semi-subjective term that could make someone go crazy and drive motorcycles across the country for the rest of their lives).

You found that '..the structure and internal quality attributes of a working, non-trivial software artifact will represent first and foremost the engineering requirements of its construction, with the influence of process being marginal, if any.' -- or in plain English: "the app specs had a much bigger influence when compared to internal efficiencies".

I would wonder if you're just seeing a statistical wash-out. Are you dealing with data sets (tens of millions of lines and thousands of functions) that are so large, that patterns simply get washed out in the analysis?

Oh dear, my post is no more clear than the summary...

Re:statistical wash-out?

[Junior J. Junior III]

in plain English: "the app specs had a much bigger influence when compared to internal efficiencies".

It sounds more like they're saying "If someone built it, and someone else is using it, and it's important, then the code quality is going to be pretty good. If it matters, it's going to get attention and be improved."

Of course, I can think of a bunch of counter-examples in Windows where something was important *to me* and mattered *to me* and no one at Microsoft saw fit to do anything about it for decades.

Re:statistical wash-out?

[raddan]

With regard to the guy who went crazy and drove his motorcycle across the country-- I think the point of the book was to demonstrate that "subjective" and "objective" are specious terms. Science gets all hot and bothered when words like "good" and "bad" are used, but not when words like "point" are used. So if we can make allowances for axiomatic terms, why not so-called "qualitative" terms? After all, the word "axiom" means, according to Wikipedia:

The word "axiom" comes from the Greek word axioma a verbal noun from the verb axioein, meaning "to deem worthy", but also "to require", which in turn comes from axios, meaning "being in balance", and hence "having (the same) value (as)", "worthy", "proper". Among the ancient Greek philosophers an axiom was a claim which could be seen to be true without any need for proof. Indeed, if you look at many of our "quantitative" measures, they are, at their heart, a formalization of "goodness" and "badness". If you're a mathematician, you might argue that this is not true (since there are loads of mathematical constructs whose only requirement is simply self-consistency and not some conformance to any external phenomenon), but if you're an engineer, you're whole career balances on the fine points of "goodness" and "badness". It is an essential concept!

My personal opinion is that if statistics are a wash-out in general, then the researcher is asking the wrong questions. I know that the author pre-defined his metrics in order to avoid bias, but that's not necessarily good science. Scientific questions should be directed toward answering specific questions, and the investigatory process must allow the scientist to ask new questions based on new data.

There is clear non-anecdotal evidence that these operating systems behave differently (and, additionally, we assign a qualitative meaning to this behavior), so the question as I understand it is: is this a result of the development style of the OS programmers? The author should seek to answer that question as unambiguously as possible. If the answer to that question is "it is unclear", then the author should have gone back and asked more questions before he published his paper, because all he has shown is that the investigatory techniques he used are ill-suited to answering the question he posed.

Slashbots are teh 13 year olds blah blah blah

[spun]

Well, you lose your bet, been over five minutes and no anti Microsoft screeds let alone spelling it with a $.

Just so everyone understands, the tactic used here is known as "Poisoning the well." The idea is the discredit an argument's source before the argument is presented. Here, our AC friend is trying to ward off criticism of Microsoft by insinuating that anyone who does so is a 13 year old "Slashbot."

The fallacy is in the fact that even someone who is 13 and often goes along with the Slashdot zeitgeist may still have legitimate criticisms of Microsoft, such as the fact that Microsoft sucks giant hairy donkey balls.

Really?

[jastus]

I'm sorry, but if this is what passes for serious academic computer-science work, close the schools. This all appears to boil down to: quality code (definition left to the reader) is produced by good programmers (can't define, but I know one when I see his/her code) who are given the time to produce quality code. Rushed projects by teams of average-to-crappy programmers results in low-quality code. All the tools and management theories in the world have little impact on this basic fact of life. My PhD, please?

Re:Really?

[jjohnson]

If you'd RTFA, you'd know that there's a lot more to what the author said than that. He says nothing about a relationship between the quality of programmers and the quality of code; he says nothing about the time taken to develop code, and makes no conclusions about its effect on code quality.

What he says is that a cluster of metrics that collectively say something general about code quality (e.g., better code tends to have smaller files with fewer LOC; worse code has more global functions and namespace pollution) show little difference between four kernels with diverse parentage.

He speculates (and says he is speculating) that obvious differences in process might account for small variances in where each kernel scores well or badly.

The 99% Solution

[SuperKendall]

So while looking at the data collected, I had to wonder if some of the conclusions reached were not something of a matter of weighting - I saw some things pretty troubling about the WRK. Among the top of my list was a 99.8% global function count!!!

This would explain some things like lower LOC count - after all, if you just have a bunch of global functions there's no need for a lot of API wrapping, you just call away.

I do hate to lean on LOC as any kind of metric but - even besides that, the far lower count of Windows made me wonder how much there, is there. Is the Windows kernel so much tighter or is it just doing less? That one metric would seem to make further conclusions hard to reach since it's such a different style.

Also, on a side note I would say another conclusion you could reach is that open source would tend to be more readable, with the WRK having a 33.30% adherence to code style and the others being 77-83%. That meshes with my experience working on corporate code, where over time coding styles change on more of a whim whereas in an open source project, it's more important to keep a common look to the code for maintainability. (That's important for corporate code too - it's just that there's usually no-one assigned to care about that).

Re:The 99% Solution

[Yosi]

The piece of Windows they had did not include drivers. It says:

Excluded from the kernel code are the device drivers, and the plug-and-play, power management, and virtual DOS subsystems. The missing parts explain the large size difference between the WRK and the other three kernels.

Much of the code in Linux, for instance, is drivers.

Re:The 99% Solution

[Diomidis Spinellis]

So while looking at the data collected, I had to wonder if some of the conclusions reached were not something of a matter of weighting - I saw some things pretty troubling about the WRK. Among the top of my list was a 99.8% global function count!!! I guess Microsoft uses a non-C linker-specific mechanism to isolate their functions, for instance by linking their code into modules. But yes, this is a troubling number.

This would explain some things like lower LOC count - after all, if you just have a bunch of global functions there's no need for a lot of API wrapping, you just call away. The lower LOC comes from the fact that WRK is s subset of Windows. It does not include device drivers, and the plug-and-play, power management, and virtual DOS subsystems.

Also, on a side note I would say another conclusion you could reach is that open source would tend to be more readable, with the WRK having a 33.30% adherence to code style and the others being 77-83%. That meshes with my experience working on corporate code, where over time coding styles change on more of a whim whereas in an open source project, it's more important to keep a common look to the code for maintainability. (That's important for corporate code too - it's just that there's usually no-one assigned to care about that). About 15 years ago I chanced upon code in a device driver that Microsoft distributed with something like a DDK that had comments written in Spanish. The situation in WRK is markedly better, but keep in mind that Microsoft distributes WRK for research and teaching.

Re:The 99% Solution

[Diomidis Spinellis]

I've put the data and the SQL queries on the web. It is therefore easy for you to do what you suggest, because the filenames are stored in the database. Just perform a cascade delete for the files you think that don't belong to each system's core and rerun the queries. I'd be interested to know the results.

KLOCs?

[Baavgai]

If good code and bad code were a simple automated analysis away, don't you think everyone would be doing it? What methodolgy could possibly give a quantitative weighting for "quality"?

"To my surprise there was no clear winner or loser..." Not really a surprise at all, actually.

Re:KLOCs?

[getto man d]

Exactly. Automation excludes creativity. If it were that easy I could just do the following:

writeGoodCode(int numberOfLines, float ouncesOfCoffeeConsumed)

Re:KLOCs?

[Diomidis Spinellis]

You can automatically recognize some bad smells of poor quality code. However, this will still let through poor quality code that has been explicitly written to guard against the bad smells. So, you can say for sure that some code stinks, but you can't (and I suspect you will never be able to) tell that some code excels.

Re:Closed Source?

[zeromorph]

The WRK is under the Microsoft Windows Research Kernel Source Code License. I'm not sure that this license conforms with anyones definition of open source, but it's reasonably free for reasearch.

But PP addresses a crucial point, if something really is closed source there is no reviewable way to compare and present this code. So if the WRK would be total crap they could always say: yes that's only the WRK, not the real kernel.

Only statements about open source code are directly verifiable/falsifiable. One of the reasons, why the FOSS approach is superior from a scientific as well as technical point of view.

The winner is still open source

[abolitiontheory]

Does anybody see that these results are in still favor of open source? The fact is, it's actually a beautiful thing that the difference in quality is marginal. This equality then becomes the rubric by which to judge other elements of the design process, and choices about whether to develop and deploy programs with open source or closed source.

People make claims about the need for closed source all the time, usually revolving around the need to a predictable level of quality, or some other factor. The fact is, this results proves that its a wash whether you choose open or closed--so why not choose open?

There's a deep significance here I'm failing to capture completely. Someone else word it better if they can. But there didn't need to be some blow-out victory of open source over closed source for this to be a victory. All open source needed to do was compare--which it did, clearly--with closed source, in terms of value, to secure its worth.

So....

[jellomizer]

The way you choose to license your software doesn't coralate with software quality... Seems logical to me. As how you license your software has very little to do about the code inside the OS.

Closed Source Developer: I will try to do my best job as I possibly can so I can keep my job and make money because that is what I value.

Open Source Developer: I will try to do my best job as I possibly can so I can help the comunity and feel better about myself/get myself noticed in the comunity/Something cool to put on my resume... because that is what I value.

People who choose to license their software OpenSource vs. Closed Source says nothing about their programming ability. There are a bunch of really crappy GNU projects out there as well as a bunch of crappy closed source projects... Yea there is the argument of millions of eyes fixing problems but really when you get millions of people looking at the same thing you will get good and bad ideas so the more good ideas you get the more bad ideas you get and the more people involved the harder it gets to weed out good ones and bad ones. Closed source is effected often by a narrow level of control where bad ideas can be mandated.... All in all everything really ballances out and the effects of the license are negledgeable.

An interesting point..

[SixDimensionalArray]

I haven't seen anybody else comment on the fact that the statement that the quality of the code had more to do with the engineering than the process through which the code was developed is quite interesting.

From my personal experiences, it typically seems code is written to solve a specific need. Said another way, in the pursuit of solving a given problem, whatever engineering is required to solve the problem must be accomplished - if existing solutions to problems can be recognized, they can be used (for example, Gang of Four/GOF patterns), otherwise, the problem must have a new solution engineered.

Seeing as how there are teams successfully developing projects (with both good, and bad code quality) using traditional OO/UML modeling, the software development life-cycle, capability maturity model, scrum, agile, XP/pair programming, and a myriad of other methods, it would seem to be that what the author is saying is, it didn't necessarily matter which method was used, it was how the solution was actually built (the.. robustness of the engineering) that mattered.

Further clarification on the difference between engineering and "process" would strengthen this paper.

I went to a Microsoft user group event some time ago - and the presenter described what they believed the process of development of code quality looked like. They suggested the progression of code quality was something like:
crap -> slightly less crappy -> decent quality -> elegant code.

Sometimes, your first solution at a given problem is elegant.. sometimes, it's just crap.

Anyways, just my two cents. Maybe two cents too many.. ;)

SixD

What I took from it was:

[jabjoe]

"Linux excels in various code structure metrics, but lags in code style. This could be attributed to the work of brilliant motivated programmers who aren't however efficiently managed to pay attention to the details of style. In contrast, the high marks of WRK in code style and low marks in code structure could be attributed to the opposite effect: programmers who are efficiently micro-managed to care about the details of style, but are not given sufficient creative freedom to structure their code in an appropriate manner. "

How ever I was left wondering how it was possible to compare fairly? He already stated:

"Excluded from the kernel code are the device drivers, and the plug-and-play, power management, and virtual DOS subsystems. The missing parts explain the large size difference between the WRK and the other three kernels."

and reading I see even more of the drivers aren't there:

"The NT Hardware Abstraction Layer, file systems, network stacks, and device drivers are implemented separately from NTOS and loaded into kernel mode as dynamic libraries. Sources for these dynamic components are not included in the WRK. "

http://www.microsoft.com/resources/sharedsource/licensing/researchkernel.mspx

So it's not like for like. Maybe you would draw different conclusions if it was, maybe the Linux style issue is because of all the drivers the WRK lacks. So even though I think his conclusion sounds probable, I don't feel I can state it as so with any confidence.

Stupid metrics

[Animats]

The metrics used in this paper are lame. They're things like "number of #define statements outside header files" and such.

Modern code quality evaluation involves running code through something like Purify, which actually has some understanding of C and its bugs. There are many such tools. This paper is way behind current analysis technology.

Re:Stupid metrics

[Diomidis Spinellis]

It took me about two months of work to collect these metrics. Yes, running in addition the code of the four kernels through a static analysis tool would have been even better, but this would have been considerably more work: You need to adjust each tool to the peculiarities of the code, add annotations in the code, weed out false positives, and then again you only get one aspect of quality, that related with bugs, like deadlocks and null pointer indirections.

Using one of the tools you propose, you will still not obtain results regarding the analysability, changeability or readability of the code.

"Code quality" is bunk

[mlwmohawk]

Sorry, I've been in the business for over 25 years and had to hear one pin head after another spout about code quality or productivity. Its all subjective at best.

The worst looking piece of spaghetti code could have fewer bugs, be more efficient, and be easier to maintain than the most modular object oriented code.

What is the "real" measure of quality or productivity? Is it LOC? No. Is it overall structure? no. Is it the number of "globals?" maybe not.

The only real measure of code is the pure and simple darwinian test of survival. If it lasts and works, its good code. If it is constantly being rewritten or is tossed, it is bad code.

I currently HATE (with a passion) the current interpretation of the bridge design pattern so popular these days. Yea, it means well, but it fails in implementation by making implementation harder and increasing the LOC benchmark. The core idea is correct, but it has been taken to absurd levels.

I have code that is over 15 years old, almost untouched, and still being used in programs today. Is it pretty? Not always. Is it "object oriented" conceptually, yes, but not necessarily. Think the "fopen,"fread," file operations. Conceptually, the FILE pointer is an object, but it is a pure C convention.

In summation:
Code that works -- good.
Code that does not -- bad.

Re:"Code quality" is bunk

[Llywelyn]

There is a company that, at the heart of their business, exists a 6000 line SQL statement that no one understands, no one can modify, and occasionally doesn't work without anyone knowing why but a restart of the program seems to take care of it.

It has lasted that way for a very very long time.

Is it good code simply as function of its survival and (sort of) working?

I tend to think of good code like good engineering or good architecture. Surely you wouldn't define good architecture as "a building that remains standing," would you? The layout of the rooms, how well that space is used, how well it fits the needs of the users, how difficult it is to make modifications, etc all factor in to "good design" and have nothing to do with whether the building "works."

I am not sure you can put a metric to it anymore than I could put a metric to measuring the quality of abstract expressionism or how well a circuit is laid out--there may be metrics to aid in the process, but in the end one can't necessarily assign a numerical rating to the final outcome for the purpose of rating.

That doesn't mean that there isn't such a thing as good quality and bad quality code.

Re:"Code quality" is bunk

[Diomidis Spinellis]

Coding to achieve some code quality metrics is dangerous, but so is saying that code that works is good. Let me give you two examples of code I've written long time ago, and that still survives on the web.

This example is code that works and also has some nice quality attributes: 96% of the program lines (631 out of the 658) are comment text rendering the program readable and understandable. With the exception of the two include file names (needed for a warning-free compile) the program passes the standard Unix spell checker without any errors.

This example is also code that works, and is quite compact for what it achieves.

I don't consider any of the two examples quality code. And sprucing bad code with object orientation, design patterns, and a layered architecture will not magically increase its quality. On the other hand, you can often (but now always) recognize bad quality code by looking at figures one can obtain automatically. If the code is full of global variables, gotos, huge functions, copy-pasted elements, meaningless identifier names, and automatically generated template comments, you can be pretty sure that its quality is abysmal.

Re:"Code quality" is bunk

[mlwmohawk]

Is it good code simply as function of its survival and (sort of) working?

"sort" of working is not "working."

exists a 6000 line SQL statement that no one understands

This is "bad" code because it needs to be fixed and no one can do it.

Surely you wouldn't define good architecture as "a building that remains standing,"

I'm pretty sure that is one of the prime criterion for a good building.

Your post ignores the "works" aspect of the rule. "Works" is subtly different than "functions." "Works" implies more than merely functioning.

Re:"Code quality" is bunk

[mlwmohawk]

You can say that if the code is functional, reliable, usable, efficient, maintainable, and portable, then it is of high quality.

Not to put too fine a point on it, but this is too much concern over stuff that does not always matter.

I agree "functional" and "reliable" are absolutely important.

"efficient?" Only if efficiency is required or of any concern. How efficient is efficient? It is a balance of efficiency against economy.

"Maintainable?" Sure, most of the time, but not always. Sometimes we toss stuff on purpose. Some good code can be written that is near to impossible to maintain. Some code sacrifices maintainability for performance.

"Portable?" There is little sense in making some code portable. PIC software, for instance, can not be good "PIC" code and portable because the PIC is such an insane type of device.

I think your cute little chart is all well and good for a common segment of software development, but it is hardly an absolute and puts too much emphasis on an arbitrary set of criteria that don't reflect the purpose or economy of software code.

This is virtually baseless

[malevolentjelly]

It's a well known fact that code will always resemble the institution that produced it, to some extent. To describe the Microsoft code as "poorly structured" is likely a bit out of touch.

The absolutely best kernel code is generally extremely beautiful and descriptive when dealing with the system's abstracts (with nice, long descriptive names for each function) and then unbelievably hellish and ugly in the sections that deal with hardware. Kernels represent an intersection between the idealistic system code and the hideously complex and inhuman machine interaction code. For this reason, we gauge the value of the systems based on how cleanly they compile into assembly, their performance, and ideally how well they do what they were written to do.

Kernel code fills such a complex role in the computer science paradigm that it is likely impossible to gauge the value or quality of any of them through any sort of automated means. What we have here is a mess of a research paper that comes to no obvious conclusions because they didn't really discover anything. If it were of any value, its final summary and conclusions wouldn't be so obfuscated. The researcher may or may not have mastered the art of understanding the zeitgeist of kernels but he certainly hasn't mastered the research paper.

No Clear Winner, but...

[rthille]

Statements like this: "Indeed the longest header file (WRK's winerror.h) at 27,000 lines lumps together error messages from 30 different areas; most of which are not related to the Windows kernel." Allow me to feel smug in my anti-Windows bias :-)

Re:No Clear Winner, but...

[Diomidis Spinellis]

Ten years ago I wrote an article criticizing the Windows API. Most of what I wrote then, continues to be true today. Based on that external view of Windows, and the BSODs I regularly see, I was expecting to find in the kernel many worse things. The header file you mention is a clear manifest of an inappropriate design, and I suspect that at higher levels of system functionality (say OLE or the GDI) there will be more parts of similarly bad quality.

NetBSD is the one to compare here

[Khopesh]

Isn't NetBSD the system filled with academics who insist upon clean, manageable, and portable code above all other standards? Too bad the NetBSD kernel didn't get judged here, I suspect it would have taken the cake.

I still recall this exhaustive report comparing several kernels' performance back in 2003 in which NetBSD pretty much beat the pants off of everybody else (note the two updates with separate graphs). The initial poor performance was due to an old revision, and upon seeing that there were some places in which the newer revision wasn't so hot, the developers fixed them and in only two weeks, NetBSD beat out FreeBSD on every scalability test. Their pragmatism and insistence on quality code finally paid off.

Ever since seeing those charts, I've been waiting for Debian/NetBSD to come out...

Re: my kernel comparison link

[Khopesh]

Oops, it needs a trailing slash: http://bulk.fefe.de/scalability/

Weird logic

[BokLM]

"An earlier study on the distribution of the maintainability index [4] across various FreeBSD modules [35,Figure 7.3] showed that their maintainability was evenly distributed, with few outliers at each end. This makes me believe that the WRK code examined can be treated as a representative subset of the complete Windows operating system kernel." How are FreeBSD and Windows related ? You conclude something about Windows source code based on things you saw in FreeBSD source code ?

Re:Closed Source?

[X0563511]

That works the other way too... the real windows kernel could be full of shit, and they would look better for the review of the WRK.

Re:Makes no sense anyway.

[daedae]

You: "There's obviously a problem with a study that takes 8GB of data and concludes that there's no difference in quality between kernels with legendary uptimes and those that can't manage memory well enough to stay up more than a few weeks." From the summary: "The areas I examined were file organization, code structure, code style, preprocessing, and data organization." These have no direct correlation to uptime. Yes, indirect, perhaps, as in "a better-organized kernel is easier to understand, debug, and reason about", but not direct as in "implementing the scheduler in 3 files instead of one guarantees stability." That said, what defines this as an interesting but impractical study? Doesn't it say something that there's something more fundamental than just high-level software engineering principles at work in the relative qualities of kernels?

Re:So....

[Diomidis Spinellis]

The way you license code can't directly affect its quality, but the way you develop it can. Here are some possible ways in which a company can affect (positively or negatively) the quality of the software:

• Have managers and an oversight group control quality (+)
• Through its bureaucracy remove incentives to find creative solutions to quality problems (-)
• Pay for developers to attend training courses (+)
• Provide a nice environment free of distractions that allows developers to focus on developing quality software (+)
• Buy expensive tools that can detect quality problems (+)
• Developers take their paycheck for granted and loose interest in what they are doing (-)
• Developers write obfuscated code for job security (-)

And here are some possible ways in which an open source development effort can affect (positively or negatively) the quality of the software:

• Volunteers are more motivated than paid employees (+)
• Nobody takes responsibility for the overall quality of the code; responsibility is diffused (-)
• Working conditions can be suboptimal (-)
• Developers work part-time (-)
• Developers eat their own dog food and therefore care about their code (+)
• There are many eyeballs to spot code problems (+)
• There are no marketing pressures to deliver substandard work (+)
• Developers are geographically dispersed and can't communicate easily (-)

Both lists can be expanded, and many of the arguments can be refuted. Still you get the idea: the inputs to the two development processes differ substantially and this could affect quality.

Preprocessing: here we go again

[ThePhilips]

The high marks of Solaris and WRK in preprocessing could also be attributed to programming discipline. The problems from the use of the preprocessor are well-known, but its allure is seductive. It is often tempting to use the preprocessor in order to create elaborate domain-specific programming constructs. It is also often easy to fix a portability problem by means of conditional compilation directives. However, both approaches can be problematic in the long run, and we can hypothesize that in an organization like Sun or Microsoft programmers are discouraged from relying on the preprocessor.

That subjective conclusion is precise effect reading too much into the metrics.

Sun or Microsoft programmers need to support 2 and 2 platforms respectively. (Sun: SPARC and AMD64; M$: IA32 and AMD64). All portability are of boolean complexity.

But FreeBSD and Linux run on dozen of platforms. I do not know how it is in BSD land, but in Linux first and foremost requirement for platform support, is that it has no negative side-effects on other platforms. Consequently, for example, under Linux most (all? - all!!) locking is still implemented as macros: on uni-processor system with preemptive kernel feature disabled all in-kernel synchronization would miraculously (thanks to preprocessor) disappear from the whole code base. To make sure that on such platform, kernel would run as efficiently as possible - without any locking overhead, because all the locking is not needed anymore.

And that's single example. There are many macros for special CPU features: depending on platform it would be nop or asm statement or function call. No way around using macros.

I think one of the points the author needed to factor in, is portability of OS. Without that, most metrics are skewed too much.

P.S. Actually, Linux affinity to macros is often (at least from words of kernel developers) stems from poor optimization of inlined functions in GCC. Many macros can be converted to functions - but that would damage overall level of performance. In many places significantly.

Re:question

[Diomidis Spinellis]

what was the most foul comment you encountered :D ? and where did it reside Decency laws in various parts of the world, do not allow me to answer this question. However, I can say that in total the four kernels contain in C files 18389 comments marked XXX. The most famous Unix comment is of course the well-known "You are not expected to understand this". See dmr's page for more details. This is also an interesting comment, especially considering the current troubles of the person who wrote it.

pointless handwaving

[nguy]

Those statistics are useless; nobody has any idea how these measures translate into correctness, robustness, or performance.