Rabiator wrote: But even if I had money in the game, I'd vote for "take your time to do it right".
I second that, as long as we all agree that doing it right means completing
it as well. While I don't really care about the effective release date, I do hope that business Josh has:
- a list of feature,
- a time estimate (realistic to conservative) for all of them, potentially dividing into required and nice to have elements (so a minimum time and a desired time),
- a list of critical things (where the feature is not only a "sweat" implementation problem, but where the solution needs yet to be developed, and therefore where a timeline is very hard to set) to start with them first to decrease uncertainty; I repeat, this is highest priority, so graphic Josh or "known" stuff are only for Sundays...
With this he can make a priority of stuff to do to clarify the unknowns (developing until a solution is found and time effort can be evaluated for full implementation, not until completion). Note that after 1 year of development, these unknown should be relatively seldom, so this first step should be completed quickly.
Finally there is a list of feature without major unknowns that adds up to a development time.
Double it (this includes unexpected stuff, balancing work, impact of a new feature to work with the others seamlessly and so on), add 2 month for beta and feedback.
If what comes out is summer 2014, fine. Otherwise take now the decision to cut features (either reducing the nice to have to the required lower level, or striking completely - sorry guys, no mining/research/whatever in LT1.0) or adapt the timeline.
Follow up then your plan according to the effective work done to get as early as possible the feel if your timeline remain realistic.
As this is definitely NOT a fun thing to do, and as pressure works well, I would suggest making it publicly, with a dedicated mid-month post to update and communicate the status. You would have a development movie every month and a timeline update on the 15th, at least here in the forum.
Yes, this is control
. Trust is good, but control is better...
I am sorry to always sound negative, but this is actually the toughest part of software development. Programming is comparatively easy... I hope you understand that my aim is to increase the probability of you delivering a finished product in a useful time, not to put pressure for you to be quick.