At 08:28 PM 4/9/2007, you wrote: >Ditto for software. If you want software fast, expect low quality.
Not necessarily. That may be a good analysis for the state of RAD software now, but the one doesn't necessarily lead to the other. Besides, the point being made isn't about speed so much as it is showstopper bugs getting into the releases. I mind slowness of startup of RB only when RB crashes on me continually and I have to restart it all the time. >How does one measure the BQ "Bug Quotient" of a piece of software >before it's released? The company tests it! That's the way it's always been done. Although these days companies use public betas to help matters, and I don't have a problem with that. I think RS's system is a good one. The problem, though, is that too many showstoppers make it in the releases. That's what this thread is about. Ultimately that's RS's responsibility, not the public who have been invited to beta. >Although steps have been taken in the field of 'software >correctness', I think early pioneers caught on when they realized >that there is NO way to conclusively prove that a software program >doesn't have any bugs. That isn't good history. The "pioneers" had to debug their work conclusively. They didn't have an easy way to update software, so a bad release could be absolutely fatal. And sometimes it was. From what I read consistently, software in the 70-80-90's was tested-tested-tested and was expected to be as close to bug-free as possible. I never have read anything where any firm threw up their hands and said "software just doesn't work sometimes". Remember the classic challenge of the Donald Knuth in TeX? He said that he'd pay $20 for every person that found a bug in his program, and he intended to double it every year the program existed. Read "Writing Solid Code" (Microsoft Press) by Steve Maguire. The illusion that programs with any significant bugs should exist is shattered in his Introduction. I don't think there's any doubt that companies have used the modern faster delivery systems to speed releases and back off of software quality. I hope that's not a off-the-cuff remark, but the temptation is incredible, and I see it given into numerous times, in my company and also in most that I work for. But again, the point here is "show-stoppers that make it in releases". All I know is that I use a 6-8 year old copy of Visual Basic and it crashes very seldom. I can honestly say it has no show-stoppers. I never ever have any inkling to even upgrade to VB6 for the reason of productivity. Not so with RB. RB isn't filled with them, they are very few, but they are upfront enough to cause serious concern. They've wasted several hours of my time already. If they were user-error or had workarounds I'd be the first to use them and not complain (constructively, hopefully). But not these. >Let's lighten up, people. Hopefully, now that RS is using RB to >build RB, they can clear up a lot of the doodlypoop in 2007r2. I actually would rather that they used something more low level. Using RB to do RB makes for a nice happy ending, but it makes for a rough ride in the meantime. But speaking very pragmatically, when it gets to the point it makes absolutely no difference to me at all how RS makes RB. Certain programs are work programs, like a sound editor, a DAW (digital audio workstation) a word processor, a graphics program, or a IDE like RB. They are the foundation of peoples livelihood. They need to be rock-solid. Your band saw may be touchy, but not your screwdriver. Features are nice, but in stuff like this the program has to be rock-solid and give the user confidence that it'll be up and running for 8 hours straight. RB is that type of program. And that's why it causes a stink when the "rock-solidness" is compromised, even in the smallest degree. So, whatever it takes is fine with me, whether cow-dung is used in the memory-manager or it's leftover sandwiches. Reasonable speed for common functions, no crashing, and all basic functions work as advertised. * * * * * * * * * * * * * * * * * * * * * * * * * * * | Garth Hjelte | | Customer Service Representative, President | | Chicken Systems, Inc, Rubber Chicken Software Co. | | 714 5th Street SE | | Willmar, MN 56201 USA | | | | 800-8-PRO-EPS Toll Free Order Line (US Only) | | 320-235-9798 Tech Support, Sampler Questions | | International Line | | 360-838-7689 Fax | | Product Sales: [EMAIL PROTECTED] | | Product Support: [EMAIL PROTECTED] | | Sampler Q+A: [EMAIL PROTECTED] | | Web Page: www.chickensys.com | * * * * * * * * * * * * * * * * * * * * * * * * * * * _______________________________________________ Unsubscribe or switch delivery mode: <http://www.realsoftware.com/support/listmanager/> Search the archives: <http://support.realsoftware.com/listarchives/lists.html>
