"Release early release often" was a mantra of "Extreme Programming", a closed-source commercial software development methodology that predates this article by about 4 years, and was au courant at the time Raymond was was writing. One of my big thematic criticisms of Raymond's article is that it doesn't seem especially in touch with how closed-source development worked at the time.
I'm sympathetic to the idea that C&B is overrated, but it was published in 1997, and XP was only being fleshed out at the C3 program in 1996. The Agile manifesto -- in 2001 -- was what gave it its major visibility bump.
Release early and often was in the air in the late nineties, but C&B was legitimately the first time many people got to hear about it.
I dispute some of this, only because I was doing a software startup from '98-'01 and we managed to hire not one but two XP devotees that dragged me into reading this stuff. To this day, though, I'm still mostly unfamiliar with the particulars of Agile.
I get that Agile was bigger than XP (who could deny that?), and agree preemptively that Raymond's article is probably the first time many people heard about incremental release strategies. That's true of a lot of things in it! My big complaint about those ideas is that they're not Raymond's --- not even in the sense of waiting to be distilled from Linux by Raymond.
The true-feeling parts of Raymond's article read to me like a document of, for lack of a better term, late 1990s programming thinking. Just a bunch of stuff that was floating in the air, a bunch of Fred Brooks, and then weird attempts to generalize design decisions in Fetchmail to the whole of software development.
I appreciate getting called on this and forced to think more carefully about it. Thanks for the response!
I completely agree with you about C&B. Even at the time, it felt to me mostly like a restatement of the zeitgeist. But Raymond was very influential at the time and was apparently one of the reasons Netscape released Mozilla as free software.
I also agree that “release early and often”, in particular, was a significant contribution, if not for originality then for reach. Not everyone was exposed to XP at the time, but ESR seemed to be everywhere. And for my part, the main take away from XP had been around pair programming which as a startup myself, I wasn’t into/couldn’t afford/didn’t subscribe to anyway.
But I do feel your comments about XP and agile miss the mark a tiny bit. XP was developed by Kent Beck - who went on to be one of the authors of the Agile Manifesto. Perhaps because of this, XP is considered an agile practice.
But agile is really just a set of values and principles. There are many practices that people claim as “agile”, many of which do not meet the criteria of the agile manifesto (I’m looking at you, SAFe).
I think in some ways, C&B was a precursor to the Agile Manifesto, which itself it arguably just a restatement of principles and practices that already existed.
(My limited personal experience with engineering in large traditional companies is that the manifesto is ignored, commercial practices and consultants who slap “agile” stickers on their traditional SDLCs still rule - and it is still, largely, the dark ages. I was heavily criticised for using a CD strategy for some enterprise software at the same brand name company that required me to enforce password rotation… in 2018).
Things certainly happened very quickly in that period -- it's staggering to think that 1997 was only four years after the web began to percolate, and C&B I think got its lift because it happened when Netscape decided to open source their browser.
It's definitely hard to work out a chronology when things are piling one after the other, and also there wasn't the same consistency of knowledge propagation. It was still very hard to find out new things online.
> a closed-source commercial software development methodology that predates this article by about 4 years, and was au courant at the time Raymond was was writing.
I think you are misremembering. Check out the Wikipedia article on Extreme Programming [1] - The book Extreme Programming Explained wasn't published until 1999. Kent Back didn't even start working on the idea until 1996.
In any case, I'm not arguing that the idea of "release early and release often" was complete unheard of, but I am arguing that it was definitely not the standard and I would say the idea had more detractors than adherents at that time. There was still very much a battle between "waterfall processes" and "agile processes" that was really just starting to get going in the late 90s.
Is Extreme Programming a closed source commercial software development methodology? What makes it so?
I went through a period of my career where I dived head long into it, read Kent Beck's book, liked what I read. Tried pair programming, TDD etc, loved it. Found team that felt the same and had a great couple of years.
Given the book, the many conference talks etc and comparing it to other flavours
of agile that went full corporate (Scrum, SAFE). I'm surprised to hear it described as closed source.
My impression of XP at the time was that it was a methodology designed for consulting firms, and that most of its force came from the idea that it was an insurgent effort at reprogramming stodgy waterfall development processes at big companies; all of those companies --- the whole client base of XP consulting firms (which I'm assuming was a big thing) was closed source, because almost everything was at the time.
When working alone remotely from home, I simulate pair programming with a methodology I call "The Stranger". I sit on one of my hands until it becomes numb and tingly, and then it feels like somebody else is typing and moving the mouse!
