Estimated reading time: 2 minutes
“It will be ready when it’s ready.“
If you work in the software industry, I am sure you have heard some variations of this statement. It was probably a close neighbor to a rant about how deadlines kill the productivity of dev teams. I wouldn’t be surprised if someone threw the word “arbitrary” in there somewhere to add some drama.
Let me tell you why this is wrong.
Software can’t be “ready” before it’s shipped.
One of the signs of a healthy codebase is an active issue tracker. It should list many issues and enhancements, host discussions about these, be consistently triaged, and prioritized.
The keyword here is “prioritized.”
Without prioritization, an issue tracker only becomes an overwhelming idea and bug report graveyard. In random order, with no notion of effort or impact, developers can’t see the end of it, as new issues are opened faster than they can be closed. Real people using the software are the best tool you have at your disposal to prioritize that list.
Shipping is the best prioritization tool at your disposal.
You don’t know the answers beforehand.
Heck, most often, you won’t even know the questions. If you do not break down your work into small size chunks, which you can regularly ship to test your hypotheses and (in)validate your assumptions, you’ll be building a product that nobody out there wants. You are trying to solve an actual problem real people have. Listen to them.
You can’t listen to them if you don’t ship anything.
You are not working alone.
Last but not least, you must understand that your flexibility ends where the flexibility of others begins. Any medium-sized project requires the collaboration of multiple people across teams and roles. They have other commitments, and their ability to plan is the best guarantee of the overall success of your enterprise.