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."
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".
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.
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!
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.)
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.
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).
Replace "learn <language>" with "port <program> to <language>" and it can be directly applied. It would probably help if there was an existing test-suite for you to measure progress against.
"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."