[NUG] *Re: API 2.0

[Norman Palardy]

> On Mar 14, 2019, at 9:31 AM, Jon Ogden via Nug <nug at xojousers.com> wrote:
> 
> 
>> On Mar 14, 2019, at 10:09 AM, Norman Palardy <npalardy at great-white-software.com> wrote:
>> 
>> 
>>> On Mar 14, 2019, at 7:58 AM, Jon Ogden via Nug <nug at xojousers.com> wrote:
>>> 
>>> My point exactly.  I had filed a bug report and it’s probably still open or closed as unreproducible.  The big gripe of most users is that instead of fixing things, Xojo just keeps going ahead and adding more stuff or changing stuff.  Take Serial Ports there’s a status bug with them as reported here: <feedback://showreport?report_id=14952>  In face the mailer doesn’t format Feedback links right it is case 14952.  This has been verified since 2015.  Verified.  Means that Xojo reproduced the bug.
>> 
>> No
>> It means "this behaves as described"
>> Verified isn't "Verified this is a bug"
>> Those statuses aren't clear in that regard and this is a constant source of pain and conflict internally and externally
>> It would be nice to have that status say "Verified this behaves as stated" or something much more complete and then extra statuses for "verified as a bug" or something
>> 
> 
> Norman, come one.  That’s a terrible excuse and it doesn’t make logical sense in probably 99% of the cases.

Its not an excuse Jon - its an explanation of what VERIFIED means that you just refuse to listen to
Its literally what it means - no more no less
Stop assuming you get to define what it means or that you know what it means - it means what Xojo says it means and thats how they treat things. Based on THEIR definition of what verified means.
You can rail at me or them but thats like trying to turn the USS Enterprise by standing on the shore and blowing spit balls at it out in the middle of the Atlantic.
Unlikely to have any effect.

Stephane and Robin arent product engineers nor do they have access to the source code - so the MOST they can do is verify that something behaves as a report describes
The only person(s) who can say this is definitely a bug or not are the engineers

But there is not "Verified as a bug" status 
And so we have - right here on this little thread - the exact problem I mentioned

YOU think verified means "verified as a bug"
And I'm trying to tell you that it NOT what it mean at all
Believe me or dont - it matters not - that IS what it means, that IS how Xojo treats it

The single BEST way to get your bugs fixed is to provide a reproducible case with an example
There are bugs that literally got reported & fixed in less than an hour after the report was filed because the example/steps made it so easy to track down the issue.
Even in things like sockets and timers and lots of other really low level bits like the compiler.

> If a user documents something that is clearly different from what the documentation says and that clearly gives different results like it does in this case, then it’s clearly a bug.

More likely the documentation is wrong

> Once Xojo verifies that something behaves improperly, then what else would you call it?

They have NOT "verifies that something behaves improperly"
Stephane or Robin -or whoever marked it verified - has verified that it behaves as described - no more no less
And this is not synonymous with "and its a bug"

>  Swiss cheese?  Makes as much sense.  Maybe it’s too soon after being gone from Xojo and the Xojo Reality Distortion Field (XRDF) around you has not faded away enough yet.

Nope
This has ALWAYS been the case whether it was feedback or the previous web based system or whatever
The statuses simply dont have the granularity to say "received", "reviewed", "behaves as described" "is a bug" (or not and closed as not a bug) etc

Maybe they should just change the Verified status to "behaves as described"
It would be more correct

> Let’s see, “We have verified that this behavior as documented by the customer does indeed match what the customer claims.  It is not working as we describe in in the documentation nor is it working consistently.  But it’s not a bug.  We are calling it an undocumented feature.  Yeah, that’s it.  We just verified that the bad behavior you saw does occur.  But we are too busy building big new features to worry about what problems customer may have to work around."

You have "“We have verified that this behavior as documented by the customer" 
Dont stretch this out to mean something it doesnt mean or that you assume it means - it does not mean anything beyond "it behaves as described"
It may be the fix is to correct the documentation - this happens quite a bit.

>>> But it’s 4 years later and it’s not done.  And actually the first report of this was in 2010!!!
>> 
>> I honestly dont know why they ever did what they did with the baud rates turning them into numeric constants that arent just the baud rates themselves
>> That would have made more sense
>> 
>>> So why not FIX stuff first then move on instead of compounding error on top of error.
>> 
>> Fixes dont sell new versions.
> 
> No.  They retain customers and make customers thrilled who then continue to use the product, continue to renew and tell their friends about it.  A buggy software results in a lot of one time purchasers who then trash the product online and don’t evangelize and recruit others.

Seriously Jon - bug fix releases DO NOT - sell more anything
I worked there for a decade
I know this to be 100% verifiably true

What does ? Black Friday and Programmers Day sales
Those two sell far more than any assumed bump from fixes might

Really

>> In most fields getting people's attention is driven by big new features - and a long list of bug fixes doesn't get a lot of attention.
>> Its hard to get any of the news sites to mention a release that is a long list of bug fixes.
> 
> And that’s part of the problem.  It’s being driven by the “news” sites and not by actually building a product that is truly robust.  There’s been a LOT of long time customers who have left Xojo because of the unfixed issues.  These people haven’t renewed and they haven’t brought in others.  In fact, they have probably trashed the product on forums and told others to stay away.  But that doesn’t make it to news sites either.  The XRDF functions great because the news sites have a big story about how Xojo is embracing iOS.  Never mind the framework was a shambles and left the user to define many, many controls through declares.  Now there’s a news story about Android or this or that.  Half-assed job gets done and the bugs never get fixed or the framework improved because now we are on to the next thing just to drive the news cycle.  XRDF generators functioning at full capacity.

news sites also need to drive eyeballs and "bug fixes" dont do that for Xojo or the news sites
advertising does drive sales and news like "hey were doing iOS" works as a great ad on the news sites
do I like it ? no 
But it what what pays the bills so thats what you do

>> Basically bug fixes releases don't affect the revenue model and so they aren't common
>> 
> 
> Actually they do, way more than you think or realize.  Part of your revenue model is customer retention.

You have no idea what Xojo's revenue model is, what assumptions its predicated on etc
You're guessing
They've been in business for 20+ years - so they do know their market reasonably well - and they do a pretty decent job of hitting it

My contention is that they dont try to grow that market to more full time developers and focus on the citizen developer almost to their detriment
But I no longer have to beat my head against that brick wall

> Don’t get me wrong, I love Xojo and I’m all in on it.  But I’m disgusted by the fact that so many choose to look the other way and not address problems that should be fixed.  Instead new layers are just piled on which creates more bugs, etc.

Trust me - every engineer knows both sides of this
New features do drive sales. They have a monthly meeting where all this is discussed and that is the 100% unvarnished truth
Bug fix releases do NOT see any significant bump in sales or renewals
Releases with big new features (iOS, Web, 64 bit) do

So its not that they ignore bugs - they pick and chose which ones to fix that have the broadest impact and then add features
Every engineer has literally said at one time or another "gee it would be nice if we could fix ..." followed almost immediately by a discussion of how often is it encountered / reported/ etc. Bugs with lots of reports are investigated and IF they can be reproduced are scheduled to be fixed.

And thats generally what you see in the release notes on every release.