MaidSafe Dev Update :safe: 8th December 2015

I’ll be happy to buy you a beer. Maybe at a party in Troon some day, just don’t ask me when :smile:

3 Likes

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? :smiley:

8 Likes

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.

3 Likes

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.

7 Likes

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.

2 Likes
3 Likes

@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.

@happybeing

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.

1 Like

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.

1 Like

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.

6 Likes

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.

6 Likes

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.

2 Likes

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 :slight_smile:

7 Likes

You say this, which echoes the opinions of several here, but we’re now at post 100 on this topic and yet nobody has addressed the issues raised against it in order to make a case for this view.

There seems to be a belief that more reliable estimates should be possible at this stage than have been given to date (each sprint is an estimate - usually two to three weeks), but I don’t see the reason why that should be the case. I’ve explained why I don’t think it’s feasible, or helpful to give them regardless.

I’m sure MaidSafe will take these views into account, they have always tried to do what the community wants, but unless someone can make a good case for this I hope they’ll stay cautious.

Once reliable estimates can be produced, for less complex, “been here, done that” code and tools, MaidSafe will I’m sure be able to give more in this respect. But we are still dealing with the core, never done before features, and still relatively early days using a new and evolving toolset.

Frankly, I think the best thing MaidSafe can do to respond to these concerns is get Rust-5 out there, and then move into the next sprint.

Clearly this discussion would not have happened if they’d achieved Rust-5 even last week. We’d all be busy playing with the network. This is in large part understandable community disappointment and anxiety, because this has been a big bump at a time when we’re on the verge of something really fantastic. It’ll be back in track soon I’m sure, and everyone will be much happier and these calls will die down to their previous level. And MaidSafe can get on with the important work of the next sprint, tweaking the network and adding features.

1 Like

Wow, 102 replies to this update, that’s definitely a record

1 Like

I thought all the major issues raised have now been addressed …well were addressed around 60 posts ago…lol. I’m not sure what everyone’s arguing about still. I said some time ago that I had answers from devs that satisfied my concerns, I think @Seneca said a similar thing and most of the others are quite happy I think.
We’ve been told “weeks” for Rust 5/basic Network, then we’ll be in a better position to do Roadmap of when all the extra bits get added - with estimated timescales.
Basically, they’ll be better able to give timescales once Rust 5 done.
The ongoing debate about whether devs should give timescales has been decided already - they will…lol
What am I missing? :smiley:

3 Likes

I’d like the software to be released when it’s ready, and not before.

https://wiki.debian.org/ReleaseWhenReady Sometime in the next 12 months would be nice, but it doesn’t really matter to me.

I’d also like the Devs to not burn out under pressure. Some of the “we’ve been working all night” stuff makes me wonder.

Remember to go outside. Go for a walk, take a day off, go to the pub!

It’s in the long-term interests of this project that the devs have a reasonable work/life balance and a healthy working environment.

2p

Sam

4 Likes

Any one know when the next sprint is going to be? Rust 6

1 Like

Lol…yes that update thread lasted the whole week!..which leads us nicely into the !5th Dec update. :smiley:

5 Likes

The timeframe would be

  • finish up RUST-5 - fixing the bugs and deliver on the planned activities of RUST-5
  • As people try out the code there may be a few more touch ups to be done
  • Planning for RUST-6 – 1 to 2 weeks is the typical timeframe for planning
  • List of activities for RUST-6 will be released
  • Doing Rust-6
  • Bug fixing
  • Somewhere in all that will be time off during the holiday season for the devs to spend time with families etc.

We are really at the business end of the code, that is producing something that can work globally, even though it is not feature complete. So I’d expect there to be a series of whack-a-mole situations on the bugs because at this time they are bringing together the modules and testing them for real life operation.

I’d say that after testsafecoin has (RUST-6 or 7) completed and tests OK then estimations on timeframes will be possible/better because the unique innovations will have been traversed and simple feature additions are easier to set approx timeframes for.

8 Likes

A post was split to a new topic: SAFE URL: use a real internet domain such as safenetwork.net