Quality, reputation, and improving both (was Re: text copied form LC generated PDF, WTF?)

[Richard Gaskin]

dunbarx wrote:

 > Several threads on the forum have bemoaned what is labeled an
 > overarching bug issue in LC.
...
 > I am really only concerned that LC not get a reputation for being
 > unstable.

Most of us share that concern.  To assess the issue soberly compels us 
to examine the nature and sources of reputation.

Reputation is only partly a reflection of actual technical fitness. The 
rest is a mix of factors that lie far outside of computer science, into 
the realms of psychology, sociology, and political science.

This thread is a good example:  What might have seemed at first like a 
bug in LC turned out to be a limitation inherent in the nature of PDF 
itself.

On the forums we see a another, with surprising frequency:  when the 
behavior of a script is not understood, the poster will sometimes 
surmise that the cause is somehow file format corruption. Many cases 
turn out to be just syntax errors, and IIRC few or none of those have 
turned out to be file format corruption.

We see a similar pattern with the documentation: many posts point to a 
need for additional information being added to the docs, with 
recommendations for learning basics linking to any of a wide range of 
resources spread out across the web, but on further examination we find 
that the fairly comprehensive 655-page User Guide included with the 
install hadn't yet been consulted at all.


None of this is to suggest that LiveCode is the world's first 
million-line code base that's completely bug-free.

But neither is it a roach motel when we consider the scope and 
complexity of the system with common metrics like bugs/kloc.


In the vast gulf between needlessly contentious allegations of 
"apologists" at one extreme and "Henny Pennys" on the other is a middle 
ground where meaningful product improvement can actually happen:

- Let questions be questions:  When an unexpected outcome is observed, 
we can keep an open mind about possible causes until the issue is 
diagnosed.  If we keep telling new users in advance that every 
unexpected outcome is a bug in LC they'll eventually believe it, even in 
the many cases where that isn't true.

- Let learning happen right in the box: We are blessed with a great many 
contributions from community members all across the web.  But to be 
clear, many of these predate the expanded documentation effort the team 
undertook several versions ago.  Moreover, those written after LC 
adopted an open source workflow missed the opportunity for greater 
readership, keeping them in a relatively small corner of the 
possibly-discoverable web rather than submitting them to the core docs 
every user is directed to right in the Help menu.  The docs are good, 
and can always be made even better.  We can help. Of course we want to 
see as much LC info everywhere, but core basics might just as well be in 
the box, and we do a good service to the learner to let them know when 
they already are.

- Let pre-release builds realize their value:  use them, whenever 
practical.  Putting off trying a new version until after Stable is the 
one choice that guarantees any issues affecting your specific work won't 
be fixed in that version.  We know from our own experiences and decades 
of industry literature that the earlier in the process bugs are 
identified, the less impact they have, and thus the total systemic cost 
to address them is much lower.


These are just suggestions, and certainly not any attempt at 
establishing any sort of "rules".  I have no authority to require anyone 
to do anything, nor would I even try, as I understand that from time to 
time there can be good reason to ignore each of these, and any other 
common practices observable in healthy software communities.

But most of us have been around the block enough times to recognize the 
value of such ordinary practices.  And all of us want LC to improve - 
both in terms of actual product quality, and its *perceived* quality, 
its reputation.

LiveCode is moving its way up the TIOBE Index of programming language 
popularity, slowly but steadily. For all the reasons Geoff Moore 
outlined in Crossing the Chasm and many more, expanding LC's audience 
benefits all of us: more tools, more libraries, more eyeballs, more hands.

There isn't a single language on the TIOBE Index that's bug-free, and 
yes, that includes LiveCode.

We the community have at least as much power and influence over LiveCode 
adoption as anything the core team can do, by virtue of our numbers and 
reach.  With any programming tool, the number of end-users who 
ultimately benefit is orders of magnitude larger than the number of 
developers using it.

Let's produce great work, and build upon those practices proven across 
the industry to expand both real and perceived quality.



Along those lines, I'll extend an offer here:

 > For my part, I only notice that LC 9x crashes intermittently, though
 > regularly. I must add that I am working mainly on a single project
 > when this happens, and am conditioned to save often. The other
 > projects I have currently do not exhibit this at all, though that
 > may be simply due to the fact that I am involved in them much less
 > intensely.
 > I suppose it is less worrisome that this is a problem in only a
 > single project, than if it happened here and there, everywhere.

Crashers are of course serious, but the good news is that you're only 
seeing it in one project.  Feel free to email me directly if you're in a 
position to allow me to review the errant code, and I'll see what we can 
do to both find a workaround to keep your progress moving along well, 
and submit a report for the underlying cause once we find it.

-- 
  Richard Gaskin
  Fourth World Systems
  Software Design and Development for the Desktop, Mobile, and the Web
  ____________________________________________________________________
  Ambassador at FourthWorld.com                http://www.FourthWorld.com