

The Rapid Release Tautology - swombat
http://www.modernperlbooks.com/mt/2009/04/the-rapid-release-tautology.html

======
lsb
It's cyclical, but it's a virtuous cycle, not a tautology, as the article
itself states:

"The only realistic way I know of to release software frequently is to start
to release software frequently. You will probably fail the first few times you
try. If your release process is painful, it will continue to be painful until
you identify and eliminate the causes of the pain."

~~~
mechanical_fish
They're using the word "tautology" as a sort of ironic joke.

I agree that they should have chosen "virtuous cycle" instead. "Tautology" is
too cute, cute enough to be misleading. I clicked through to the article
expecting it to be some kind of rant about how you Should Never Release
Software Before It Is "Done".

------
10ren
Weekly releases: the first thing that came to my mind was that you need
features that _can_ be done in a week.

If they can't be, you need to subdivide them. Subdividing is the way to tackle
any difficult problem, so maybe it's good to be forced into it anyway.

I've been putting off a release, because it (looks like it) requires some
fundamental changes. If I found a way to subdivide it, and release it, that
would be a great way to move forward.

------
rs
FTA: The biggest change is that trunk must always be stable. You can work on
whatever features you like, as long as you keep the trunk of the project in a
releasable state. You must be relentless.

This is where distributed source control comes in really, really handy!

------
ananthrk
_tying the release date to the calendar, not to any particular feature_

(Just thinking aloud) Can this be applied to other areas (like _"learn
Language X"_ )?

~~~
sokoloff
Yes and no. The problem is the [lack of] specificity of the goal. You either
did or did not release software on date X(+). To say whether you did or did
not learn a language by date X is too fluid to be particularly helpful. If you
did literally nothing, then you clearly failed; otherwise, it's all just
shades of grey.

\+ - One can argue whether or not you got "enough" features/tickets/bug-fixes
into what you did release, but that's the beauty of regularly scheduled
release "trains". If a feature misses one train, it just hops onto the next
one, which is never very far behind. We do three-week cycles and have been the
entire 6 years I've been here. When I first joined, I didn't see any way we
could keep it up and argued against trying. Now, I can't imagine how our
company would continue to run if we didn't have that 3-week heartbeat. (We are
a IR top 100 e-tailer, over 200 technical staff, over a dozen "large" projects
in flight at once, etc. Not every project goes with every release, but the
entire site, fulfillment and support systems all go every 3, 4 weeks over
Thanksgiving and Christmas/New Years.)

~~~
eru
Perhaps you can just "name and shame". I.e. say you want to learn language x,
then force yourself to report in public upon your progress every monday. You
will feel whether you made good progress --- and you will definitely know when
you did not do a thing.

~~~
ananthrk
Yes. This will be similar to "committing to a release date" (no matter what)
and figuring out ways to achieve the same. We can also draw other parallels
like "keep improving" (without incurring _long-term debts_ ).

