MobileRead Forums - View Single Post

TuxGirl · 04-25-2017, 03:31 PM

Petercreasey:

As a software developer (not for e-readers, but still), I might have some thoughts that might help you understand this issue...

1) all software of a non-trivial size has bugs. How big, and how easy to run into varies, but it all has bugs.
2) you generally don't want the majority of your customers running into the big bugs
3) you may have to have 60% of your userbase running a specific piece of software before you find out about a huge bug.
4) generally, it is bad to push new software to everyone at once, unless your sample size is particularly small or the changes are particularly trivial
5) it is utterly impossible to find every single bug before pushing to production

I remember at one point we were pushing out some new software at an old employer. We had it set to take less than 1% of requests first. Then, we had it take progressively more, very slowly. We blacklisted the CEO's account from using the new system until we had been handling 80% of requests with the new system for over a week with no major issues. Why? Why should the CEO get his requests pushed through the old system when so many other people were getting the new system? Well, because Murphy's law states that the CEO was more likely to run into issues than anyone else, because he would be furious...

Anyway, in terms of updates for devices, I honestly think the smartest way to push out would be similar to what Google does with Android releases. Have a public beta, where anyone who knows how to install the software themselves and wants to can do that and run the new software for a while. When that appears to be reliable, then slowly, gradually push to the rest of the public.

Generally, you are better off having your more technical users be the ones to run into your bugs. Why? Well, for one thing, they aren't going to panic. Also, they are going to write better but reports, and so be able to provide the right information to help debug the issue. On top of that, since they self-selected, they have less basis to point fingers and say that you messed their stuff up.

04-25-2017, 03:31 PM	#113
TuxGirl Groupie Posts: 179 Karma: 141378 Join Date: Sep 2009 Device: kindle	Petercreasey: As a software developer (not for e-readers, but still), I might have some thoughts that might help you understand this issue... 1) all software of a non-trivial size has bugs. How big, and how easy to run into varies, but it all has bugs. 2) you generally don't want the majority of your customers running into the big bugs 3) you may have to have 60% of your userbase running a specific piece of software before you find out about a huge bug. 4) generally, it is bad to push new software to everyone at once, unless your sample size is particularly small or the changes are particularly trivial 5) it is utterly impossible to find every single bug before pushing to production I remember at one point we were pushing out some new software at an old employer. We had it set to take less than 1% of requests first. Then, we had it take progressively more, very slowly. We blacklisted the CEO's account from using the new system until we had been handling 80% of requests with the new system for over a week with no major issues. Why? Why should the CEO get his requests pushed through the old system when so many other people were getting the new system? Well, because Murphy's law states that the CEO was more likely to run into issues than anyone else, because he would be furious... Anyway, in terms of updates for devices, I honestly think the smartest way to push out would be similar to what Google does with Android releases. Have a public beta, where anyone who knows how to install the software themselves and wants to can do that and run the new software for a while. When that appears to be reliable, then slowly, gradually push to the rest of the public. Generally, you are better off having your more technical users be the ones to run into your bugs. Why? Well, for one thing, they aren't going to panic. Also, they are going to write better but reports, and so be able to provide the right information to help debug the issue. On top of that, since they self-selected, they have less basis to point fingers and say that you messed their stuff up.