Software Engineering: Failed profession or not? Windows vs Linux kernel

A fascinating read by a Windows Kernel developer about the social dynamics of Linux vs Windows kernels.
The post raised in me three reactions:

• Comments quickly become "TL;DR" not just diminishing, but negating their value.
• There may be some good content in there, but it's lost in the noise after a very few comments...
• The whole value add of (good) writing in general, and journalism in particular, is the "value-add":
• condensing complex topics, including all relevant facts and drawing non-obvious, interesting relationships and conclusions. "Food for thought" is what writers should be aiming at to gain and maintain readership, not just for vanity or ego-boosting & adulation/acclaim by fanboi's.
• But the web has yet to understand that "quantity is not quality", in fact the reverse, "more is less" when it turns good, insightful prose into a deluge of noise to be shifted through endless drivel, trolling and judgemental crap in the comments.
• Writing is easy, we all come with language, a desire to be heard and a sense of "I have an equally valuable opinion, thought or comment".
• Good writing is hard - it takes time, effort and help to condense a first draft into a tight, punchy piece.
• Great writing is exceedingly rare and like musical "hits", is not formulaic, never predictable and often only recognised in hindsight. It always starts with Good writing, the same way it works for music/performance: "How do you get to Carnegie Hall? Practice, Practice, Practice!"
• After a decade-and-a-half of blogging and webpage comments, nobody I've seen has cracked the code of extracting the gems from the usual PoS of comments.
• This is NOT as simple as voting (+/-) on comments-as-written.
• It's the Art and Craft of sub-editing: recognising the gems in amongst the dross, reframing them as necessary, putting the important stuff first and dropping everything that isn't necessary.

• One of the commenters tried the "you don't know history" line. I found it ironic that there is some great history that almost nobody is aware of: extracts from Jerry Landsbaum's 1992 book, "Measuring and Motivating Maintenance Programmers" and some of comments on the importance of Metrics.
• Landsbaum reported on simple, cost-effective and quantitatively testable methods of improving Code Quality, lowering maintenance costs and improving average programmer productivity by 25-50%. It wasn't "rocket science" or "smartest guys in the room" stuff: it was applying sound Engineering and People management.
• Jerry's work is critically important to the current work of collectively maintaining large bodies of important code: all kernels, windowing systems and Tools & Applications.
• I must check if the Linux kernel folk know of his work or have rediscovered his techniques... From the Windows developer comments, we know that Microsoft doesn't.

• In the past, I've written on the failure of both I.T. as a Profession and of Software Engineering. Uniquely, we can read all about the inception of a discipline and note they didn't define what success would like look, nor how they'd know if they were improving things.
• The nub is simple: neither Learn systemically nor can provide metrics justifying their existence.
• This is why I assert that Software Engineering is a failed discipline: it cannot demonstrate, either internally or externally to employers, that what is does is worth a crumpet.

That's my criticism of both sides of the Windows Kernel vs Linux Kernel "debate": neither side embed Learning and Improvement in their daily processes, neither can provide numbers to sustain their arguments. This is not a debate amongst Professionals, it's more ideological shouting matches.

The Linux Kernel folk might argue that their code is "cleaner", "better", "faster" and "more secure/robust" than other code trees but they can't prove it with metrics.

The Discipline covering exactly this area and that should be able to resolve these "arguments" after 25 years and hundreds of millions of dollars cannot address the most basic and necessary question:

Is this code better than that code? In what ways and do they matter to the Owner, Client and User?

The more nebulous and far more relevant question for practising Professionals is:

How elegant is the code, How clean is the design?