I’ve referred a couple times to deadlines and schedule pressure as constraints one should embrace to make a great app (or similar software project). It’s a good cheat at forcing priorities, especially useful for version 1, where everything is so loose and open.
Deadlines, though—everyone knows—can be used for nefarious purposes as well.
I started this project with the intent to ship when iOS 10 ships. Apple has its event tomorrow, 7 September 2016, likely announcing the iPhone 7 and most definitely providing a true ship date for iOS 10. It’s either this Friday or a couple weeks off.
I’m nowhere near ready to ship. I’m hewing to the principal of keeping a small feature set and calling YAGNI (You Ain’t Gonna Need It) when needed, to expedite. But I’m probably going to miss that date.
Did I fail? Truly?
If I hadn’t told anyone at all about this project until I was ready to ship (or least beta test) and then just came out with it, no one—no one—would have told me, “too bad it was three weeks late.”
Yet, internally to a project team (the cross functional one, not just the dev team) there is tremendous pressure ship on a particular date. The more behind the team is on features and bugs, the more work there is before the deadline, the greater the pressure. This pressure (and the deadline) is entirely self defeating if there is too much to do before the deadline.
The team will burn out, the software won’t be very good for developers to work in or users to use, your business sputters. But, hey, you hit your date, right?
Brian Valentine, the executive responsible for shipping Windows 2000 (which apparently was a troubled project) and several other Windowses is reputed to have said it best:
No one cares that you shipped on time if your software is shit.
The project itself should be assessed constantly. Move quickly, yes, but don’t assume anyone cares about your software ship date, even if you’re big, even if you announced it beforehand. If you’re huge, like Apple, and you slip your date, the tech press will cry foul, analyst projections may be missed; but six months from now, no one will care and will barely remember.
Keep the quality high instead.
For an MVP, if you’re totally happy with it, you took too long; if you’re totally unhappy with it, you shipped too soon.
Ship date is an artificial constraint in many cases. Some times it’s necessary to acknowledge the artificial part.
I’ve referred to this tweet before, in the post where I said having a date is a good thing:
"I've set the wedding date. I've not asked her out yet." - how software projects are managed.
— Farbod Saraf (@farbodsaraf) February 16, 2016
So: Kapowski is not going to make the ship date I chose. But I’m happy with the progress; we are getting there.
We’ll ship late but won’t be shit.