Quote from: James on June 24, 2014, 10:47:50 am

我看到了stan的回复，我觉得如果我不是生活在中国的话，也许看到这些话会非常激动，很可惜，我生活在一个充斥着表决心和画未来的国度，所以我还是希望stan能够正面回答我的问题，而不是和我们阐述也许会有也许永远不会有的未来。

1. BM能否集中精力在开发，而不是在论坛回复，你们有没有能力管住他，还是公司没有任何人或者机制可以限制他在论坛上无休止的回帖。
2. BM时间是否充足到可以每天在论坛上发帖，而项目不需要他太多的精力？
3. Bitshares项目什么时候可以出来，有没有具体的时间节点和deadline? 在您40年的开发经验中，是否项目管理都是没有时间限制的？
4. 在什么情况下我们可以认为项目开发已经失败或者失控？如果一旦发生，你们有没有后备计划？

请Stan正面回答我的问题，而不是继续说一些纯粹鼓舞的话，谢谢。

I very glad to see the Stan's answer, if i dont live in china, maybe i will so exciting to hear that. but so sorry, i'm living in china, we can hear this sentence everyday, so, i hope stan you can answer me question directly, not just draw great picture for us.

1. can BM focus on developing,  don't waste too many time on reply posts. can you or 3I can control his reply, dont let him answer question too far, or he is out of control?
2. does BM have enough time to answer the question, you say he have so many time on developing, but we can see he put more time on forum
3. when bitshares will be seen a stable version? can you give me timetable  or deadline? you said you have 40 years experience on R&D, is your project management all never have any timetable?
4. which situation we can consider that project is failure or out of control? when it happened, do you have any plan B?

sorry about me poor english , please answer me question directly first, thank you.

These are excellent (and fun) questions, so I will try to answer them.

1. can BM focus on developing,  don't waste too many time on reply posts. can you or 3I can control his reply, dont let him answer question too far, or he is out of control?

BM has developed the discipline to occasionally go several hours at a time without looking at the forum.  He has attempted to clear his schedule of all activities except development and manages to squeeze about 6 hours of personal coding and 6 hours of working with individual engineers on their specific assignments.  These twelve hours are spread across a typical 16 hour day, leaving him four hours every day for other mentally stimulating tasks to be mixed in as rejuvenating breaks (often while his code is compiling).  That leaves him about 8 hours for sleeping and other important biological functions.

2. does BM have enough time to answer the question, you say he have so many time on developing, but we can see he put more time on forum.

Time on the forum is used as a rejuvenation break or a background task while compiling or running a test.  It is his way of "staying in touch with the street"  Eliminating this time would actually reduce his productivity.

3. when bitshares will be seen a stable version? can you give me timetable  or deadline? you said you have 40 years experience on R&D, is your project management all never have any timetable?

I think we are very close, judging from the most recent test results on the forum. Today I noticed this encouraging quote:

Quote from: alt on June 24, 2014, 08:10:36 am

very stable up now.
thank you, I3 team. 

As for making timetables, I have done hundreds in my career.  Their utility varies with project type. 

If you are running a repeatable assembly line process, like building a row of identical houses, then you can get very good schedules.  But even these are subject to uncontrollable events like weather, worker accidents, supplier delays etc. 

If your project is making something new, like a more advanced aircraft, then you have to find whatever aircraft is most like it and look at historical data from its development and extrapolate based on an estimate of where the new invention risks are.  Generally, such programs are given a cookie cutter schedule with generic milestones like System Requirements Review (SRR), Preliminary Design Review (PDR), Critical Design Review (CDR) and Test Readiness Review (TRR).  These are spread out over several years so there will be plenty of time to find and fix problems.  On big programs there will often be parallel risk reduction efforts that work on developing technology long before it is needed.

As you move up in risk toward Research and Development projects that are specifically intended to break new ground, the schedule is usually determined arbitrarily by the sponsor based other considerations like budgetary cycles.  Here the task is to make as much progress as possible with a given budget of time and money.  So the manager's task becomes one variable deliveries within a fixed budget.

In our case, we are developing something that has never been done before with a team that has never worked together before.  There is no historical data from which to make an estimate and there is no specified deadline other than "as soon as humanly possible."  We do have considerable flexibility in defining our own requirements but in the end, we need to deploy mission critical software that must be trusted with Other People's Money (OPM).  We try to minimize the time and money necessary by determining the requirements for a Minimum Viable Product (MVP) one that is good enough to attract permanent customers without immediately being cloned by a competitor who adds the one killer feature we thought we could safely leave out.  We have spent much time on this forum in January and February trying to assess what would constitute a MVP.  Our general strategy was to release a user friendly product (UFP) by early summer and then we took a shot at releasing an MVP in early spring.

Discovery of new vectors of attack caused us to go back to the drawing board and invent DPOS.  This took us 10 extra weeks that we didn't know we would need until the attack vectors were discovered.  In a 30 to 60 month development program, you can add contingencies to your plan to allow for unanticipated problems and if you are very lucky, your schedule doesn't slip.

But when you are trying to get a mission critical product out as soon as humanly possible, there is no padding you can add to the schedule.  You work as fast as you can and as hard as you can and you never ever ever let anyone pressure you to release the software prematurely.    People's fortunes are at stake.  You must not fail them.

4. which situation we can consider that project is failure or out of control? when it happened, do you have any plan B?

Everyone here has witnessed how we deal with failure.  We find a solution and move on.  We have actually gone through perhaps a dozen "failures" since we launched PTS.  Failures don't scare us.  Failures cause breakthroughs!  Thomas Edison once said, "I have not failed a thousand times, I have successfully discovered a thousand ways NOT to make a light bulb." 

The only unknown is how many dragons we have left to slay.  We have no doubt that we can slay them.