I agree with the first half of the article but find the "kernel" concept lacking. Here's why: It doesn't mention actual programming theory. SCRUM, Extreme Prog

I agree with the first half of the article but find the "kernel" concept lacking. Here's why: It doesn't mention actual programming theory. SCRUM, Extreme Programming, Waterfall, etc. These are all about management and business practices, not about what we do. Extreme Programming has some craft related "practices" (TDD, CI) but even these are mostly in the QA corner. I think we need a theory about classes of programming problems and their solutions. We need to analyze our code bases, and how we grew those, in order to understand the trade-offs and nature of our approaches. And by this I really mean analyze the code base, the "project idioms", the abstractions, their cooperation. Examples I recall are from the Lisp world where the bottom-up onion is a well liked strategy (layering toolboxes on toolboxes, each made up of many small pieces which can be combined effectively). Another such observation is the many types with few methods vs many functions on few types debate. This is what I want to see researched (and research myself).