Quote from: someguy09876 on August 11, 2017, 10:29:02 PM

Quote from: yosir on August 11, 2017, 10:14:00 PM

Quote from: someguy09876 on August 11, 2017, 09:33:31 PM

It's not hard to give rough estimates for a project's time frame. I work in software and something like, "We expect feature A to be complete by date X" is not unreasonable and is pretty standard. If you reach date X and feature A is not complete, then give a reasonable explanation as to why feature A is not finished, something like, "we ran into difficulties implementing feature A because of reasons B, C, and D."

This "we don't do deadlines" thing is a little ridiculous. Set reasonable time frames and, if they aren't met, give explanations as to why they couldn't be met.

I think that you not doing R&D as part of your "work in software". It is VERY HARD, near impossible to give an estimate for something that was never done before and truly innovative as you almost never can take in consideration all bumps/changes/redesigns/bugs you will meet on the way to solution. So deadlines, that you don't know if you can meet them, are irrelevant at first place. And about "reasonable explanations", how do feel about... "guys, it took me more time to solve something I thought it will take me less time" * 10? good enough for you?
And you can add to this the fact, that there is no development structure as in regular place of work in this kind of projects, with fixed (more or less) work hours, as far as I know no one pays Borzalom so I guess he keeps also day job...
Don't you think that his day job can influence his availability and change his "project time" depending on work stress? How he should give estimate for something without even knowing how much time he will be able to spend on project?

It is very easy to demand and be negative while comparing bananas with apples. I suggest next time just think about possible explanations before.

I do hope, and this is according to CCR update from few days before, that we are progressing in development and this is positive thing. As long as final result will be working product, for me it worth waiting. If someone feels different and think that this is "bad" project, he always can sell his XBY and leave it.

Yes, research and development is part of my job and I'm still required to give time estimates. I also work on personal projects on the side and if someone asked for an estimate for how long it would take to get a working proof of concept and then demo, I would be able to provide a time frame for these goals. I might not meet the estimates, but I would be able to explain why they weren't met.

I'm not demanding anything, only asking questions, and "guys, it took me more time to solve something I thought it will take me less time" isn't an explanation, let alone a reasonable one.

Where is the proof of progress? The last commit to the core code was twenty days ago and the last commit to the other xby repo is just an auto generated block checkpoint update.

See for yourself:
https://github.com/borzalom/XtraBYtes/commit/9a97dd2ed0330dda74346f39aea9a93f17220d7b
https://github.com/XtraBYtes/core

I just wonder, how you give estimate for something that was never done by you or someone else, truly innovative, not reuse someones code and stitch it somewhere with few your lines, while you don't know how much time you can dedicate to it because of dynamic main job? Please explain me as I think you give estimates where I fail to do so...
"guys, it took me more time to solve something I thought it will take me less time" this is explanation, good or not, this is something else. To what Level Borzalom should report you about delays? To give you specific issues? code lines? detailed explanations as he owes you something?
And about proof of process, this is indeed valid point but if I remember correctly one been said that updates are not fluent or something like this... not sure about it. But this is indeed issue worth to address. Basically I believe to CCR and to his update and I am sure this can be clarified before using this as some kind of evidence because maybe there is perfectly good explanation to this.