I think that's a great editorial, because it asks real questions.

But... CMM is one of my pet hates. It is a terrible idea. It tells you nothing. It builds a useless paper-chase.

Agile is another story altogether. It's just a new term applied to a bunch of things that existed and were done for decades before the term "agile" was invented. Maybe it's the wheel, reinvented as a not convex polygon (or maybe it's convex - whatever, it certainly has some nasty sharp corners)- I don't know, because I can make very little sense of it.

Decades ago I worked in a world where development, testing , quality assurance, and release were all incremental; there was no magical goal; the requirements might change; was that "agile"? We built what is probably the longest surviving mainframe operating system in the world (ICL's VME/B OS was first shipped to customers in the early 70s, and is still being shipped today, by Fujitsu; call it a contemporary of Unix if you believe that Unix was a serious mainframe OS before Ucb got hold of it and gave us BSD Unix) using those techniques. None of us had ever heard of "agile", since we were doing this long before the term had been invented to hijack as subset of well understood good software development practise; and of course the guys at Bell labs were using similar techniques, and they had never heard of "agile" either.

The difference between what we (and others) were doing and what's now called "agile" was fourfold. First, we didn't have a bunch of brain-dead hype merchants explaining to the world that what we were doing eliminated several critical necessities of the development process: the necessity to recognise that the customer might have a requirement; the necessity to do some planning; and and the necessity to commit to something. Of course no-one in the "agile" camp (as opposed to those in the sensationalist journalism camp) fails to understand those first two essentials, but some have discarded the third. Second, we didn't claim that we could vastly reduce the cost of software development by throwing away the idea that our commitment could be to something real, measurable, and quantifiable rather that to something rather vague. Third, we didn't claim that the only alternative to our approach was the waterfall method (which at least as early as 1970, was known, by everyone competent in software development, to be a recipe for catastrophe on anything but a very small project), so we were not claiming that every-one else in the world was dead from the neck up. And fourth (unlike the "agile" game , or the "OO" revolution) we were actually doing (at the same time as many others - that's how research works) something new and different, not just sticking a new label on a decades old technique.