Comment by cousin_it
7 years ago
This sounds like a great idea, can't believe I didn't see it earlier. Maybe I should adopt it for my personal projects (software, music, etc): pick a regular release schedule and stick to it, even if it means releasing less feature-rich stuff. Does anyone have experience with this approach?
Many of my personal projects have only existed because of deadlines.
If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
(that said, sometimes I wonder if I would have something much more polished with a last-minute magical 2-week reprieve)
> If you go to shows or conferences, showing or talking about something is the best way to have something, and the deadline focuses you like nothing else.
The same applies for a personal project that's delivered as a gift to a family or friend. I guess I should write sometime about the Raspberry Pi-based Christmas present I gave my father in 2014, even though he stopped using it scarcely a year later. For this thread, the point is that the deadline made this the only personal coding side project that I've completed in several years.
OpenBSD does (2 releases every year, approximately 6 months apart).
This is sort of what scrum does isn't it? Release every cycle no matter what was completed. Whatever was not completed goes back into the backlog and potentially into the next cycle.
Ideally, yes.
In practice there are often complications, however.
Usually, it's just office politics: Those cases can be quite difficult -- you really need buy-in and TRUST from management (and have to do the right political plays, etc.) to be able to cut through the bullshit and "allow" feature slips. Books have been written about this scenario.
Rarely, deadlines are imposed by Real Politics, aka: law... which can make for Interesting Times. This can range from "quite difficult" to "too easy!", so I have no advice here.
> Release every cycle no matter what was completed.
What happens when your software is in a broken state that's worse than what you had before?
I guess the keyword is, "completed". If something is broken, I doubt it would be in master, or the team has done something terribly strange. Or they should be nicer to QA ;)
Rollback to last known good state. Hopefully that's not as far back as the previous release (been there, done that, all I got was this lousy egg on my face).
You don't have tests?
I actually hate it when software teams adopt the "we will release it when it is ready" stance, because it makes it practically impossible to plan and prepare for the new version.
I am also a strong believer that it is a sign of gross lack of internal discipline, or at least severe lack of confidence. It means you still suffer from "unknown unknowns" and therefore can't come up with and stick to a proper estimate (even if it is something broad, like Q2 2019). This doesn't say good things about a software team, in my opinion.
I know very well that estimates are difficult. But, again in my opinion, going with "we will release the next version on February 20th, now let's discuss what features we can implement during that timeframe" as opposed to "here is a list of features we want in the next version, now let's discuss when we can finish them by... actually never mind, we will just tell people 'when it is ready'".
Chrome and Firefox teams have, for years now.
Java moved to this approach a few years ago. They release every six months, which IMHO is too frequently.
This is scrum.