patientlywaiting

dabigkahuna said:

TextBladeDenied said:

And yet, Mark Knighton refuses to ship it. Care to guess why

I’m always amazed at these kinds of statements since he has explained why. You may not like the explanation - but then you would be explaining why. Or you may want more detail, as I do, but then you’d be talking about that. Instead you pretend no reason has been given. 

We know how lack of free memory is at least a big part of this. We know the present firmware was said to work well enough. There is no contradiction in theses two things though it can seem that way on the surface. 

Yes, we know that the present firmware works well enough. That's why we want WayTools to ship. The lack of free memory doesn't actually affect current performance; it (and the consequent "necessity" of an immediate rewrite) is just an excuse to delay shipping.

There will continue to be issues found. Those who use it can see how complicated it is and how it is virtually impossible to find all problems that will be discovered with mass shipments. 

So they need to be able to fix those things efficiently. With no free memory, they must rewrite not only the problematic code but often other code just to make room!

1) They don't have to actually fix every problem that is reported in real time as it is reported. They do have the option to tell people that a fix is on the way in an update that is coming soon. (hee-hee, I see what I did there.) Waiting for fixes is annoying to be sure, but much less annoying than waiting for General Release. And while we wait we'd be delighted (presumably as delighted as current TREGgers) with the product in hand.

WayTools says that they aren't demanding perfection before they ship. That means they are going to have to accept that their imperfections will be out in the wild for a while.

2) Yes, they'd have to develop their current problematic code at the same time as writing the new fork. In common industry parlance, that's what a code fork means--working on 2 parallel versions of the code at the same time (hence a fork with its parallel tines).  If you just stop development on one and only work on the other, that's a rewrite. WayTools really should stop calling it a "firmware fork" and call it what it really is--a rewrite from the ground up.

Yes, developing the current code and new code at the same time is hard work. That's what they set out to do, right? A keyboard revolution? Revolutions are hard work and don't get done all in one step. They have to accept that it will get done in stages. It took Apple 3 versions before they got Cut/Copy/Paste into iPhone. They didn't delay the whole product until Cut/Copy/Paste was ready; they shipped. Real artists ship.

As many like to say, any time a feature is added or even just expanded, no matter how simple, you can create new problems. Somehow they forget all that in this case!
...

I have not forgotten. This argument is why they need to stop with the feature creep and actually freeze the feature set or they will never get around to shipping as the problems will keep multiplying. Somehow you keep drawing the opposite conclusion from this argument than you ought to.

One can claim they should do it that way anyway, but that ignores the risks of ordinary users being unhappy with the results if they are subject to any newly discovered problems. Sure, there is risk with either choice, but if you want them to go with your choice, then invest in creating your own product.

That is a false choice.

dabigkahuna said:

alexonline said:

Keep reading, Kahuna, there’s more than just that.

Still waiting for you to provide an example of what you claim they did (make digs at customers) in that section under "availability/shipping update".

@alexonline Please don't do it. Learn from my mistake. We've already had countless posts on the meaning of the well-defined term "Yes", and we don't need countless more on the poorly-defined term "dig".

dabigkahuna said:

I'm pretty sure that is because they can't be confident enough about a specific date. And, considering the many discovered issues, that makes sense.

In which case, they should probably pick the "- We really have no idea " response.

dabigkahuna said:

2. ...I don't think there is any chance that could take less than a month no matter how good the testing was over the first 2-3 weeks. Because they have surely learned that problems have popped up many times before. So that moves us to sometime in October, AT BEST. ...

You are finally getting it. This is why I was insisting years ago that their estimate of "this month" (for any given month when they said it) was unrealistic (especially when it was the last week of that month) and that they needed to give real, honest estimates instead of the automatic "next [time period]" estimates which is what they (presumably) thought we wanted to hear.

I argued that their estimate-making process was broken since it always outputted "next [time period]" even if the input was something along the lines of "we just discovered a hardware issue that requires a serious overhaul and redesign of the butterfly switches". Somehow you interpreted that as me arguing that they should make less *frequent* estimates instead of a call for an overhaul of how they make their estimates in the first place.

dabigkahuna said:

And remember, a lot of these "problems" are really going to be user error. I can't emphasize that enough, but because of how it works, they ARE going to think it is the product rather than themselves. So they'll have a base percentage of user support demands that aren't the fault of WT. The more they can limit those issues that ARE something they can fix ahead of time, the better.

This is mindboggling and ironic since this was originally one of my complaints on the WayTools Forum--which was that no amount of firmware improvements will solve user error. Somehow you've managed to twist it backwards into a rationale that essentially demands perfection (even though you and WayTools have explicitly said that they are not demanding perfection). With this thinking, no matter what, it is always justified to delay for improvements for the sake of people who will blame WayTools for their own errors regardless.

They say they don't require perfection to ship, but every visible action and all of their other stated rationales that I've seen indicate that they think otherwise. And all of your statements indicate that while you would be happy for them to ship now, you are also fine with them delaying any amount of time to reach any arbitrarily high level of quality that they are satisfied with (i.e. perfect in all but name).

dabigkahuna said:

So, as a BUSINESS decision, the greater risk...

To me it isn't about which approach they SHOULD do because, as I said, I don't think there is a definitive "right" answer. To me it is about whether the decision they make seems to make sense...

Well that's the thing, *all sorts of things* can be justified as BUSINESS decisions, especially unethical ones. When we complain about what they SHOULD do, that generally implies ethics, not business. Of course there is overlap, but just saying that X decision "seems to make sense" from a business standpoint makes for a crummy ethical stance.

dabigkahuna said:
But let's say it isn't. Think about what that means if they didn't do the rewrite! 

That's not my point. My point is about the necessity of a feature freeze.