These benefits only accrue if the timescales are accurate and the one thing we can say is that the evidence shows that they will not be on this project.
The primary reason I've heard so far for not giving timescales is that they might not be so accurate and therefore are not very valuable. However, what is less accurate and valuable than even an incorrect estimate, is no estimate at all. So this seem illogical.
To me what you say here is illogical. Not having an estimate leaves the question open, whereas an innaccurate estimate is going to mislead almost everyone.
I've also heard the argument that it is not good to share timescale estimates because it might lead to disillusionment or disappointment amongst the community if it is not correct. Keeping everyone in the dark is not rational to protect the mindset of the few that aren't able to cope with the realities of estimates - that they are by definition not accurate. I would also argue that there are negative reprecussions to the sentiment of the community of an information blackout on timescale.
Yes, there are negative aspects to not having estimates. I think on balance it is better to be honest than to mislead, and that it is more negative to put out estimates that you know are unlikely to pan out.
Another argument I've heard made is that having timescale estimates in place puts undue stress on the devs. Firstly the devs here are doing what they love (hopefully) on an amazingly interesting project, with other peoples money, so I don't think that pity (wrong word but hopefully you get the idea) should be the primary emotion when we talk about their workload etc. The additional pressure of a shared timescale estimate is a very first world problem and not one I think should be taken seriously. In short I don't think the stressed dev argument stands interrogation.
You don't seem to understand the experience of developing a project with a stated time scale, because the pressure to meet such an easily judged goal is real. And because you play down the negatives of missing such a deadline, you are I think also tending to underestimate the impact of a deadline on those who are responsible for delivering it. Not just developers, but everyone involved.
The problem with that pressure, especially for a project which needs to get things right, is that it undermines the processes that deliver the other objectives. There are many ways that this has the potential to damage the project, including the release of code that is not ready, and the potential to damage the whole project as a result. This would be a very high price to pay, to give rather dubious guidance to those developers who think timescales would be helpful in this instance. It would not be in the interests of anyone who wants SAFEnetwork to succeed.
If the project is still in a place where there is simply so much left to be done that estimates are pointless because 'completion' is so far on the horizon (years away?) then sobeit, but it's best to be honest with the community, investors and app devs if this is the case.
This misses the point. It is not known how far away completion is, so to imply it is dishonest not to say it is years away doesn't make sense. It is unknown.
I know not everyone will agree with me on this post. If you don't then just know I am not trying to offend or rattle anyone's cage. If you do disagree with me please feel free to come back with counter points - it'd be good to hear them. If you do agree with me that it would be beneficial if timescale estimates were shared by maidsafe then feel free to add your own perspectives too.
No offence here. I've been involved almost daily since 2014 and so am impatient as anyone, but I can see why this is an impossible project to estimate.
While still a young developer I began estimating projects from a few days to several man years for a contract research, design and development company. It was a fantastic place to work because every project was different, and most involved doing things that hadn't been done before. In that context I quickly learned that estimating had two main purposes, neither of which was accurately estimating the timescale or cost, because that just wasn't possible most of the time:
- to enable a contract to be agreed which balanced the needs of a client to understand the potential costs, benefits and risks, with the needs of the contractor to deliver the client's goals while making a living. That sounds simple and obvious, which belies how difficult that is. In practice it was not a one-off activity, but an ongoing process from initial client contact to final delivery and signing off.
- to provide something to measure progress against, in order to spot divergences from client and project expectations as early as possible. The point of this is that you go to the client and tell them ASAP, rather than plough on and fail badly because you either met cost and time goals but didn't deliver the solution, or vice versa.
The only projects that had any chance of meeting their original costs and timescales were effectively repeat projects. In other words, the only way to estimate accurately, is if you have already done something similar enough to show you what can be expected. We are not in that position here, so I am very confident that any estimate for timescales for the remaining phases would be unreliable and of little value to anyone.
That's the key point here for me. If you accept that estimates will be inaccurate, how can it possibly help anyone to publish them?
If anyone thinks that there's a way of accurately estimating the remaining phases, I think you need to either reconsider why, or show us what that is based on.