I think this is what most of us want to hear. It’s not about precise dates, but having an idea about the order of magnitude of time we’re talking about. “Weeks” means that in the very worst case scenario it’d take up to about 1-2 months, “months” would mean it could take up to half a year. At least that’s how I think.
I like estimates, even if they turn out to be inaccurate.
If time to rust 5 completion can be reasonably measured in weeks, then time to completion of rust 5 must then be less than 12 weeks, since longer then that we’re talking months. If a detailed time line can be made after rust 5’s completion as, “everything else falls into place”, then by the words you just said, you should be able to commit to a specified year, be it 2016, 2017, or whatever, that we will have the actual network in the wild to talk about now.
I completely agree. What I’m saying is that this is unhelpful to the Devs and the project, and I’ve explained why. I’m sorry if I was too forceful in my you’s. This issue comes up now and again, and I’m as impatient as everyone (not least the Devs themselves I’m sure) so we’re all apt to have strong feelings about this.
You are free to ask, but as I’ve explained, there are good reasons for MaidSafe to be cautious and only do so where they feel comfortable.
As investors, we are both most interested in the project being successful, and as soon as possible. So I’m suggesting that people, particularly investors, would in their own best interests hold their anxiety rather than call for things that are IMO unhelpful.
You may disagree, think publishing timescales don’t put the Devs under more pressure. But I haven’t heard anyone argue that, and it appears that this was a factor in these problems - so it would be a hard case to make. I’m speaking from experience, but it is also easy to understand why this is the case I think.
Let’s also remember that MaidSafe have been giving timescales, including for Rust-5. The reason we’re having this discussion is because they overran. And overran again, and again. I don’t think it would help anyone for them to be doing more in this respect.
Hey, mate - the very fact that you in particular became worried demonstrates there was an issue and perfectly understandable under the circumstances. Your excitement at the prospect of each new dev update reminds me of my dog when I get his lead. 
The issue was just simple and understandable lack of communication, as explained. I also think coders are (by looking through thread) generally less concerned than non-coders. I believe this is because they can follow progress, whereas to non-coders, GIT etc may as well be Hieroglyphs. A lesson learned I
reckon:
…which causes FUD…
At the end of the day, @whiteoutmashups, you raised your concerns, causing an issue to be resolved and nipping in the bud any potential harmful FUD…you’re a feckin’ hero mate!
Well, I for one only wanted a bit of clarity on a rough timescale - not to alleviate any discomfort. This has now been done and the issue I and others had, addressed - to my satisfaction at least. I have to say I completely disagree with most of the rest of your post too, nor will I ever refrain from asking anything I feel like on the forum, whether asked not to or not.
The “just trust” thing, I don’t really get…I don’t mistrust anybody and I don’t think it’s relevant…or good advice!..lol. I see no connection with asking for rough time-scales to adding pressure to devs and they certainly haven’t expressed feeling any. Your post sounds a bit defensive and berating of those who brought the matter up tbh…
.
We’re getting really Off-Topic by now, but I need to add my 2 cents. Forgive me.
I’m not sure how it all started, but when I stumbled upon this project almost 2 years ago, there were already estimates given by the team. I don’t think it makes sense to debate what came first, an estimate that was given or the question that asked for it. Point is, everyone around here became accustomed to estimations. It took longer than anticipated and so weeks and months went by. Then came a change in attitude of we won’t give out time frames anymore. This doesn’t instil confidence in people who can only take the devs word and trust that they’ll deliver. It is not unreasonable to assume that there are major issues and it is unclear when and maybe even if, they can be solved. This is what’s happening here. I’m not saying that’s the case btw, just that it can easily be interpreted that way and that the way of not giving estimates is not necessarily the best route to take. There is no right and wrong in this case, but these are also valid concerns.
Thanks for saying sorry, but your post was very condescending towards everyone that raised concerns and asked questions about this topic. And there are also people in this thread that have done something for this community (no matter how big or small) although they asked critical questions, so they shouldn’t be looked down upon. One last point, although I haven’t done decades worth of software development I have done at least a decade of project management/work in the IT of a major company, so I’d say my arguments are not totally worthless or unreasonable. Just needed to get that out.
PS: Please remove the profanity from your posting, I already flagged it, but the rules should apply to everyone. Thanks 
I agree, and it is one of my faults to take the high ground in a dispute. You’re right that everyone has a right to express their views, wants etc, and I could have presented my reasoning without this, though I think it’s also hard to present the experience I have without appearing to be condescending. Some people here know a lot more about these issues than others. I don’t have a monopoly here, and you mention your own experience, but still nobody has argued against the points I made - only the manner in which I made them, and saying they have a right to ask (which I don’t disagree with). This doesn’t mean that this can’t become unhelpful and counter productive. But this was more than just asking, it was quite pointed and critical, and in one case a personal attack was made that needed responding to on the topic.
I’ll remove the profanity I quoted as you request because I don’t like to see them on the forum either (I was planning to remove it later) - I’m not sure if you’ve read the whole thread, but I was referring to one particular post and the tone of my response was very affected by this.
Agreed, that was uncalled for and absolutely unnecessary, no question about it. But to me at least for me it seemed that your posting was directed at everyone, that didn’t seem warranted to me
Just a difference in opinion and I can absolutely see your points.
But no harm done, glad that we agree. You just have to buy me a beer someday
Regarding the profanity. I don’t mind it at all, as matter of fact, I use it myself when it is appropriate, because it is a powerful tool to express ones opinion. It’s just that it should be the same rule for everyone.
I’ll be happy to buy you a beer. Maybe at a party in Troon some day, just don’t ask me when
Come on…what’s yer best guess?..lol
Edit:
Talk about taking ages…have you noticed how dated the staff photo from the crowd sale now looks?
I want the devs to take as long as they want and not be in any hurry. Relax and have a great time. And when the product is ready, it’s ready. I will gladly wait patiently. Take vacation if you want. Take care of yourselves first.
After the product is “finished” that’s when the real work begins. Make sure you are well rested for that time.
Big estimates are usually wrong, but small estimates are frequently much closer to right.
Ultimately, software is the sum of many small parts. Identifying what these are and giving thoughtful estimates is useful. It also allows iterative development, where another small deliverable is added at each phase.
We can all understand that the MVP isn’t simple and is the sum of many parts. Just having some clarity on what these are and which remain is sufficient.
Ofc, expectations need to be managed, but going too far the other way destroys confidence in the ability to deliver at all. I think we all agree that we need to avoid the latter one way or another.
This is all meant to be constructive, btw. I believe in the project and the team.
The problem is, as you say later, managing expectations.
Breaking projects down into small parts is not actually very reliable in my experience, but useful nevertheless. If you want an estimate, it’s as reliable (or indeed unreliable) to go to someone with experience and ask them to guess off the top of their head! Either way, when a realistic attempt at an estimate is made, it is usually “too long” and will then be modified.
I suggest we get away from the idea that it’s possible to estimate timescales without a comparable past example to use as a yardstick. Personally, I’d include small task estimating in that - it’s just that a 100% error in a 1day task isn’t a big deal. Unless you’ve done a similar small task with the same tools, you’re still likely to be very wide of the mark.
Yet we have to do this, even so. We have to budget, estimate time, plan, allocate resources etc. It’s just that none of this is really about getting a delivery date that can be put in a calendar. It’s about managing expectations, and adjusting them at as early a stage as possible when you start to see how fast that date is receding into the future - and begin to get a handle on what can be achieved in a given time. Thus giving whoever is paying a chance to redefine the goals to best meet their needs and budget.
The problem here is that people generally don’t know this, and no matter how many times we hear it, we (me included) will still tend to wonder if a missed target date is a failure. A sign of things being done badly, someone having messed up, there being big problems etc etc. All things you’ll find on this topic.
I’ve come to the view that the best way to handle this on this kind of development, as MaidSafe also seem to have realised, is to not publish timescales and be cautious in answering questions on this.
In this thread, all the Devs were asked to give their best guess so some kind of average could be taken. One did that a couple of weeks ago and well, it was out by 100% so far, and counting. Asking them all to do this won’t make it any more accurate, but creates pressure for all of them.
Yes, plan, create a roadmap so people can follow closely, but just don’t give out information that you know is likely to be unreliable. And that will cause problems for developers who then worry about what the community expect, think, and start saying about them. It’s distracting, demoralising, and very hard not to try and meet these unrealistic expectations of they become public. Writing good software is hard, and estimating it reliably is harder, if not near impossible.
@Secretariat415
This is true but we are in wild wild west. The competition is high. It is about striking at the right time. It is all about execution. It’ll never grow if the execution is poorly done. Plus, you want devs to get on board, and expand outwards. Etheruem got a lot of devs on board in short time.
create a roadmap
There is a roadmap with no timeline. They did this perfectly well. This is what software building blocks and timeline should look like. Promises cannot be made when software dev gives a date unless it is certain. Look at open bazaar, they promised to build and release tor version last year. It went off the rails.
This is due to us not having enough people there as opposed to anyone in particular. It was too much for the people in routing who typically tried to work too long hours and just get it working.
Hello
This is a question addressed to anyone who can answer.
David said that the issues were due to not having enough people, so i was wondering why don’t they hire more devs?
Also i’m curious to know why such project only has a few devs, openbazaar for example has had a huge numbers of contributions from all over the world. I consider maidsafe an even bigger project so why aren’t devs interested in it? does maidsafe offer certain bounty to find issues? are devs able to contribute easily?
Note: Im not saying current team is not competent enough, just saying that more eyes on the code could help.
I really appreciate the straight talk that I have come to expect. Your response is far more than I need to be satisfied for a while.
You describe the core team quite well and mention hangouts and keeping up with documentation. One personal discovery I’ve had is as time has gone on I have been working an extra 20-40hours a week on SAFE related stuff for about a year; on top of my normal 40-80hr/week day job.
I’m totally fine with my choice and how things have gone, but the updates have become very important for me because I am trying to keep a parallel cadence with my personal SAFE projects; involving the same challenges of balancing my coin/time/expectations. I don’t expect anything and fully understand my blood, sweat, and tears are all on me and my completely by choice. The thing I didn’t anticipate is how personal this project has become for me. Whenever there is love involved, emotions can spin out of control here and there. The core seems to be exactly where they should be and I wouldn’t want this project to be handled any differently, but I hope understanding and patience is a two way street.
This is a fascinating situation and probably a first (decentralized development) for a lot of people; definitely for me. I am going to try and quiet my mind a little and just follow my gut feeling for a while. I can not thank enough to every member of this community. I’m honoured to feel a part of something so amazing.
This is an issue that you can’t really just chuck bodies at, it is difficult to find the right people. This is in part due to the fact that Rust is a new language and while the eco system is growing it is still very small. Secondly, the work is demanding on the developers, it requires them to work under their initiative and solve sometimes difficult problems themselves, and while this may sound like a relatively basic attribute to have, it is surprising how many don’t have it. Finally, our location. While we have realised that we will not be able to bring the amount of people we require directly to Troon, we do require the developers to make our morning catch ups and it is generally better for collaboration if those working remotely can mirror our time in Troon. We are based in GMT time and therefore this becomes very challenging for us to effectively manage developers working in significantly different time zones.
With all that said we have been really focussed on recruitment of late, we have a new developer starting in January and @Viv and I are looking through a number of promising CVs at the moment, so things are looking up here.
We, as investors have no interest in upsetting production or the people responsible for that production. It appears that you concur and advocate that the solution to inaccurate or flawed forecasting is no forecasting at all and that is not an acceptable solution under any conditions or in any business. The one thing you need to do more than anything right now is build/repair confidence and trust in the community and from investors and potential participants/farmers. Forecast + deliver = trust, more forecast + more delivery = more trust. So forecast a deliverable with a realistic window of 90 days and start that all important cycle of back/forth trust process because MAID will have many of these cycles and will need more trust - Think Funding- Think Farming-
BTW - Im an fan of Maid/Safe and the team. Hope you get that because I dont think you do.
I agreed with the decisions to refactor the code. I agreed with the decision to rewrite in rust. I also agreed with not giving timescales when these implementations were in their infancy and timescales could only be super vague because of the huge task at hand.
We’re in a very different place right now though it seems, and to my mind the arguments around the reasons to keep any predictions from public view seem far less valid.
I am a huge supporter of the project but think we need to give the community the benefit of the doubt around their ability to deal with potential disappointment, and give the developers the benefit of the doubt that they won’t have a breakdown, or work less efficiently if their best guesses turn out to be incorrect.
This is not a call to work harder, or to hurry up, both things which I think are all but impossible from what I can gather from the hard graft going on in Troon and elsewhere. Instead it’s a request to remove predictions relating to timescales from the toxic pile and put them instead in the pile marked ‘neutral information that is OK to share’.
Anyhoo, good luck guys and keep up the hard work 
