I personally think maidsafe should start giving approximate timescales for when the project will be at the various stages proposed in the roadmap.
The benefits of this would be that:
Potential app devs can use this information to use for their own timescales and make plans accordingly (this is a big one).
Potential and current investors can use this information to decide whether or not they want to back, or continue to back the 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.
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.
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.
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.
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.
This part is true, but for every single project where developers/workers get paid. I think in crypto this part is overused, with many people (not you) starting a sentence with, “as an investor …”. This is all true, but in many cultures this is an area of huge pressure and being reminded it’s normal people’s hard earned money is a pressure that makes it tough. It’s also tough to work on unknown quantities of work with timescales for very similar reasons. In addition (I do not mean to offend or anything here, please do not take it as this) the number of folk who wish for missed timescales to crucify projects is alarming. It gives of more negatives that not, in our experience anyway, this also adds to de-motivating workers.
For me these points make timescales very difficult to predict and accurate timescales impossible as they require knowledge of all the unknowns to be made into knowns if that makes sense. I think even recently twice we have been caught with anticipated 2 week tasks that have taken over 10 weeks. Ofc we see the opposite at times as well, I don’t think it’s lack of skill, I believe it’s part of the process. Like many large projects timescales and budgets are wild guesses and whilst necessary at times to make such predictions, I feel unless there is huge reason to then best not. Otherwise we stop development and back to analysing possible timescales, but we all know they will be wrong.
I doubt any project gets the balance correct, some try and easier problems are more accurate than unknown issues to predict. I think it’s just the long slog, like cure cancer, colonise mars etc. they are all difficult to predict, but we will very likely get there and faster if we work at it in a funded manner. We are now funded and should progress at full speed to launch with as little between us and that goal. I would hope after alpha 4 that we are close enough to give realistic timescales. I hope that is not too far off the horizon though, alpha 2 is very close, alpha 3 should be reasonably close behind that I hope (several weeks, low num months). THese are personal hpes though.
Sorry, this feels like a politician’s answer, I don’t mean it to be.
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.
Would you like the project to be delivered tomorrow ?
If yes, that’s because you are fully invested and looking forward to timesacales and any hint about delivery date basically.Time is you enemy here.
If not, that’s probably because you are not fully invested, and looking forward to accumulating more. Time is your friend.
So if you shift your way of thinking, make time your friend, keep quiet, and buy more, you will be much more confortable waiting.
If you time your purchases accurately and scale your orders accordingly, then it is not the delivery that is late or early, but your timing which is right or wrong.
Actually, I think that was a better answer than most of us expected. Especially the last bit. You put yourself on the line a little by actually giving some vague guesstimates. That is appreciated, a politician would have answered a different question altogether
@dirvine thanks for the response - I’m sure this questions or variations of it are never far away when talking to investors and people intwined in some way with the project. I just wanted to bring this particular point out into the open in a straighforward manner - I’m sure I’m not the only one who wanted to ask this question.
I can see the reasons for not wanting to give the timescales. How they can be wildly inaccurate. How they can lead to additional pressure on the team, negative perception if they are missed etc. Perhaps it’s my laissez faire attitude, or the fact that I am a million miles away from the real world repercussions and intricacies of this decision but I come to a different conclusion. So I politely disagree, but that’s OK and I’m open to the fact I might not be right. Either way I respect your decision and trust your judgement.
For the record I am an investor (and a fanboy to be honest too) but in no way do I feel owed anything. The truth is definitely the other way round.
This is a key point to remember for non-devs and impatient devs alike. There’s two kinds of software, software that’s been done before and software that hasn’t. If the task at hand has been done before estimating its completion is a trivial matter (even if its for a different client with a similar but different codebase). However, if what you’re attempting has no ready precedent, then timelines become impossible (depending on how trivial the task of course). There’s no way to know beforehand how long it will take to design, test, refine and deploy a particular part of the program. Bugs always crop up when you don’t expect, and even defined behavior might later be found to be incorrectly modeled or based on inaccurate assumptions.
Okay how about this. Say we had a rough estimate, say a couple weeks for alpha 2. Then a month or two for alpha 3 and a couple more month for alpha 4. We then add the caveat that thee estimates may CHANGE a new events unfold. And as events do unfold (like bugs are found or security issues arise, or a dev gets sick or something.) then we add time to the estimate and adjust it accordingly. It’s not like “Omg we need to be done in 4 to 6 months!” It’s like “Meh we hope to be done by this fall but stuff may happen.” Do you see where I’m going with this?
I mean I get where the devs are coming from. They’re creating something absolutely new out of their heads and new problems that they aren’t expecting will arise and have to be dealt with. I get that. But at the same time it would be nice to have SOME kind of plan, even if it’s akin to “We hope to be there by spring” and we end up pulling up at the water hole in the middle of summer.
Or like breaking down tasks more so we know where we are on the roadmap. Like right now with all the talk about routing and development of APIs and everything it sounds really cool but I don’t really know how it all plays into the roadmap and getting us from A to B. Yay work is getting done. Go team. But I’m never sure how far we’ve moved towards the finish line.
Okay but we need progress bar of some kind. Some way to tell how far we’ve come relative to where we are and where we are going. If it’s not dates then we need a more detailed roadmap.
IIRC remember David saying something like we wont make it to 11 years of development before a live network (or something closely resembling) in response to an article released stating the project has been snailing for a decade. Not sure who but i think @polpolrene or @happybeing caught it and highlighted it. It was fairly recent. Might be right after the maidsafe asia talk given by krishna kumar. Either way I believe that by the end of the year all of us will be knee deep in an imperfect but very intriguing network full of apps and undeniable potential. New devs will feel COMPELLED to flock over and speed up development. We just need data chains first half and the resulting realtime upgrades. That’s it. After which you’ll want to strap into your seats boys and our newest beautiful girl @Sunshine , we’ll be begging for things to slow down for fear of having our brains melt! …
During our engineering course which included computer science, we were told by the compsci profs that whenever giving an estimate for programming to do our best estimate then multiply by 4. Well during my 4 decades it has proven to be more accurate than any other estimating for new programming projects. R&D I’ve found though is more like you say 5 to 10 times.
Mind you engineering projects are a different kettle of fish and in any project I’ve been involved with the estimate for the electronics part is easy and always take the programming estimate and times 4 it.
…
