Same here. :)

To be more gregarious, I'll use an example of my current plugin.  This thing had been in development for 9 months.  The first 5 months were alpha.  I had one person who partook as an alpha-tester.  The next 4 months were beta.  I had over 30 beta-testers covering a range of versions and systems.  But this plugin was something that I had been pursuing in one form or other for several years.  So, by the end of 4 months testing, it was becoming clear that it should be released (by popular demand) with whatever feature support existed and acknowledging that it had some flaws.  It works as expected for most users - but there are the relative few who had unending crashes using it in ways not experienced either by me or beta-testers.  Why?

Bugs like this are hard to corner and squash.  My plugin is tested personally on something like eight or nine versions of the software on two operating systems (Windows and MacOS).  I wouldn't release it without at least a cursory check in each of these.  And when I try to replicate these few crashes - I can't.  At this point, the bug hunt becomes a matter of detective work - it is not directly inherent in the plugin - it is the combination of something else and the plugin.  This is that  to which I was alluding with point #2 in my post before last.  It is very impossible to debug code that works on my end but shows instability at the other - what would I look for?  You have to get very detailed information from the user experiencing the crashes to isolate the code that is potentially related to the crash - and then try to deduce why that code may work in one place and not in another.  Programming isn't only a science - it is also an art.  Sorry to say, this is the 'artistic' part of developing and maintaining code.

C makes it easy to shoot yourself in the foot. C++ makes it harder, but when you do, you blow your whole leg off.

 -- Bjarne Stroustrup

Contact Me | Kuroyume's DevelopmentZone