-
Welcome to B4X forum!
B4X is a set of simple and powerful cross platform RAD tools:
- B4A (free) - Android development
- B4J (free) - Desktop and Server development
- B4i - iOS development
- B4R (free) - Arduino, ESP8266 and ESP32 development
Have you ever created an app...
- Thread starter wonder
- Start date
- Similar Threads Similar Threads
B4X is bug free 
No, all my apps are 100% bug free....which was/is 99% bug free? Hello world doesn't count.
The ones you call bugs we call undocumented functions.
Maybe 97%
The first debugging was when technicians carried a basket, entered the computer room, (today they call it computer case)! and collected
bugs from between relay contacts (debugging).. (real bugs that insulated relay contacts and prevented conduction). I don't know why we still use bugs
and debugging..
bugs from between relay contacts (debugging).. (real bugs that insulated relay contacts and prevented conduction). I don't know why we still use bugs
and debugging..
I have made programs that were 99% bug free, but it took a couple of years in heavy usage (and bug fixing) before I got to that point. Never in a version 1.0.
I've learned one very valuable lesson, though. Sit down and listen to my tale:
A long time ago, the company where I worked was forced to release our big flagship product before it was ready. It was also our first major product for Windows (this was in the Windows 3.11 days).
The customers had lots of problems, and the phones kept on ringing. We worked our asses off, trying to fi the bugs, but most of our time had to be spent supporting customers (this was a small company, so we both developed and supported). It felt like being in a disaster area command central.
We were afraid that we had burned our customers' trust in us, so we hired a company to do a survey for us.
When the results came in, over 90% had answered (usually, 30% is considered good), and the customers were all happy. Sure, they had problems, but they understood that a new program had problems, and they really felt that we did our utmost to help them and that we fixed the problems. One customer said something along the lines of "I'd rather have a program with lots of bugs with a company that fixes them and helps me, than having a program with few bugs and a company that doesn't care.". This, more or less, summed up the general sentiment among our customers.
So, bugs will happen, don't worry about it. The important thing is how you handle them. A well handled bug can leave you with a more satisfied customer than if there wasn't any bug to begin with (and by that, I don't mean that you shouldn't try to minimize bugs, just that they aren't a disaster).
I've learned one very valuable lesson, though. Sit down and listen to my tale:
A long time ago, the company where I worked was forced to release our big flagship product before it was ready. It was also our first major product for Windows (this was in the Windows 3.11 days).
The customers had lots of problems, and the phones kept on ringing. We worked our asses off, trying to fi the bugs, but most of our time had to be spent supporting customers (this was a small company, so we both developed and supported). It felt like being in a disaster area command central.
We were afraid that we had burned our customers' trust in us, so we hired a company to do a survey for us.
When the results came in, over 90% had answered (usually, 30% is considered good), and the customers were all happy. Sure, they had problems, but they understood that a new program had problems, and they really felt that we did our utmost to help them and that we fixed the problems. One customer said something along the lines of "I'd rather have a program with lots of bugs with a company that fixes them and helps me, than having a program with few bugs and a company that doesn't care.". This, more or less, summed up the general sentiment among our customers.
So, bugs will happen, don't worry about it. The important thing is how you handle them. A well handled bug can leave you with a more satisfied customer than if there wasn't any bug to begin with (and by that, I don't mean that you shouldn't try to minimize bugs, just that they aren't a disaster).
The most important part of having a bug free application is being able to already know what the problem is when the problem is introduced
use try catch around "every" important procedure if something fails write the result to a file or a database or even email it to yourself
This is important for one primary reason the client is never going to tell you exactly what they where doing when your application crashed they are not going to send you screen shots they are not going to help you debug it. the only comment you will receive is the "application crashed" or "it just closed"
in conclusion know what your errors are before your users report them..
use try catch around "every" important procedure if something fails write the result to a file or a database or even email it to yourself
This is important for one primary reason the client is never going to tell you exactly what they where doing when your application crashed they are not going to send you screen shots they are not going to help you debug it. the only comment you will receive is the "application crashed" or "it just closed"
in conclusion know what your errors are before your users report them..
