Comment by hn_throwaway_99
2 years ago
> What's true in it isn't interesting (... "release early release often")
This feels like 20/20 hindsight to me given that "release early release often" was definitely not the "axiom" that we think of today, and one could argue the contrary opinion was more widespread in 1997.
I can easily remember some debates at a large consumer web company in the mid 00s, where at the time we released once per quarter. We were struggling with product quality, and a large, significant portion of the software dev team argued that the way to improve our product quality was to reduce the number of our releases to something like only 2 per year. The argument was that we needed more QA time, needed more time to run integration tests, needed more time to ensure changes from all the different teams wouldn't break each other before releasing.
In our current world of CI/CD, a web company releasing only twice a year sounds absolutely insane. Fortunately the loud "slow down our releases" contingent lost (which is evident simply by the fact that this large tech company still exists - if they had reduced their release cycles as some desired I firmly believe the company would have died long ago). But I just bring this up because the mantra of "release early release often" was definitely not blatantly self-evident in 1997, and I'd argue it only became "axiomatic" after tooling support for CI/CD got much better.
"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!
3 replies →
> 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.
1. https://en.wikipedia.org/wiki/Extreme_programming
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!
I personally agree with the frequent release crowd, but my company sells a web-based SaaS product and releases quarterly, my last company released a web SaaS product 2x a year and SalesForce famously releases closer to once per year, so a large part my the world is "still insane" based on your opinion.
I was introduced to Salesforce in the early 2000s by a user very happy that useful features showed up every quarter without an upgrade process, so they have regressed substantially if this is the case.
I think it's safe to say in general that a large part of the world is still insane and will always be insane. Perhaps it's just part of the human condition.
> a large consumer web company in the mid 00s
This sounds like Yahoo!