The difference between “when it’s ready” and “YOLO” schedules
Chapter 8 of Program Management for Open Source Projects lays out three basic models of schedule: when it’s “ready”, when you reach the scheduled day, or whenever you feel like it (or “YOLO“). After I posted about this on Twitter, Fabio Valentini asked if the first and third choices are the same. Speaking of the software he develops, he said “I basically decide whether it’s ready or not based on the YOLO principle.”
It’s a great question. The difference between “when it’s ready” and “YOLO” is two-fold. Let’s look at the explicit difference first.
A “when it’s done” schedule exists, whereas a “YOLO” schedule does not. When building a “when it’s done” schedule, you figured out what changes you want in the next release and then you estimate how long it will take to complete. You add various milestones and checkpoints along the way. These provide an opportunity to evaluate your progress and make changes if needed.
The schedule is always a rough estimate at best, but the important thing is it exists. You publish — and your community relies on — a recorded plan. The plan may change, but it’s there. In a “YOLO” schedule module, you essentially wake up one morning and decide to release. The plan hasn’t changed because there was no plan to begin with.
The implicit difference is the size of the contributor community. A “YOLO” model is a valid choice if you’re the only developer. You don’t have anyone to coordinate with. Once you add a second person — particularly as an equal — you need to start coordinating. That means you need to start planning. The more contributors you add, the more likely that a “YOLO” approach can’t work.
