dewme said: Today, a lot of software development organizations follow a continuous integration/continuous delivery (CI/CD or simply CD) model which, in theory, means that every build or every daily build is in a releasable state. In other words, if they had to ship the daily build, it would be good to go and fully tested. That's the goal, but I'm not sure Apple or very many software development organizations hit that goal perfectly. Getting closer to the goal still represents a significant improvement.
It can also have the opposite effect if new requirements/features continue to be drip-fed into the proposed release. That means there is a continuous supply of new, hence immature and buggy, components.
I’m not really sure what you mean by “the opposite effect.” Are you saying that setting up your software development process in a way that allows you to be ready to release at any time is going to degrade your software quality? Introducing late breaking requirements and changes and not testing them adequately is an organization level behavioral problem that is independent of your software development process. It’s bad practice and risky. With a continuous release process this means you could be releasing a few new bugs every couple of weeks when you’ve made a small number of changes. With longer release intervals you could be releasing a big pile of new bugs after making hundreds of changes. So yeah, if the quality of your testing cannot keep up with your release frequency, you’re screwed.
I do understand the notion that the longer run time you get on your software the more likely bugs in software that has not been adequately tested are likely to crop up. If you’re lucky. For example, if you have memory leak that accumulates slowly over run time, it may only cause a system crash after 3 weeks of uptime and it may get caught incidentally, i.e., you got lucky. If your test regimen for your continuous or rapid release process only takes 3 days and you haven’t done anything to specifically verify that your software isn’t leaking memory, that memory leak bug will escape into the field. There’s less time for luck to save you from inadequacies in your testing quality.
Modern software development processes try to avoid the late breaking changes problem by managing all software work through a singularly managed product backlog, or work queue. Ideally, the work that is queued up on the backlog has been broken down into manageable sized chunks that can fit into the release frequency you need to support, where “fitting in” means meeting all testing requirements and minimizing risk. Of course this is never perfect because software is entirely dependent on humans and humans make mistakes at every level, including not recognizing the risk of introducing late breaking requirements and assuming that any sized change can fit into any sized release window.
To get back to Apple’s recent flurry of updates, I’d say that their release process is working pretty well in that each update was limited in scope and addressed very specific issues. They discovered the bug, they killed the bug, and they released an update. I would be more concerned with the frequency of updates if they discovered the bug, claimed to have killed the bug, released an update, but the bug was not really killed. If this repeated multiple times I’d say that their CD or rapid release process wasn’t working. Likewise, if each update spawned new bugs, I’d be even more concerned that not only is their CD or rapid release process not working, but they had fundamental issues with their software quality process. But so far, so good.
If you think your phone is "overheating" just go the battery monitor in settings and see what app is using battery. The ONLY way a phone can "overheat" is if an app is converting "energy" into "heat" ? Your phone doesn't magically make heat out of nothing as apparently some people think.
Basically you are right. But I still need to correct you on your advice. You have mixed up cause and effect here.
An app that causes overheating is most certainly draining that energy from your battery. But the opposite isn’t always true. Just because an app uses a lot of battery it doesn’t necessarily cause overheating of the device.
Comments
I do understand the notion that the longer run time you get on your software the more likely bugs in software that has not been adequately tested are likely to crop up. If you’re lucky. For example, if you have memory leak that accumulates slowly over run time, it may only cause a system crash after 3 weeks of uptime and it may get caught incidentally, i.e., you got lucky. If your test regimen for your continuous or rapid release process only takes 3 days and you haven’t done anything to specifically verify that your software isn’t leaking memory, that memory leak bug will escape into the field. There’s less time for luck to save you from inadequacies in your testing quality.
Modern software development processes try to avoid the late breaking changes problem by managing all software work through a singularly managed product backlog, or work queue. Ideally, the work that is queued up on the backlog has been broken down into manageable sized chunks that can fit into the release frequency you need to support, where “fitting in” means meeting all testing requirements and minimizing risk. Of course this is never perfect because software is entirely dependent on humans and humans make mistakes at every level, including not recognizing the risk of introducing late breaking requirements and assuming that any sized change can fit into any sized release window.
To get back to Apple’s recent flurry of updates, I’d say that their release process is working pretty well in that each update was limited in scope and addressed very specific issues. They discovered the bug, they killed the bug, and they released an update. I would be more concerned with the frequency of updates if they discovered the bug, claimed to have killed the bug, released an update, but the bug was not really killed. If this repeated multiple times I’d say that their CD or rapid release process wasn’t working. Likewise, if each update spawned new bugs, I’d be even more concerned that not only is their CD or rapid release process not working, but they had fundamental issues with their software quality process. But so far, so good.
An app that causes overheating is most certainly draining that energy from your battery. But the opposite isn’t always true. Just because an app uses a lot of battery it doesn’t necessarily cause overheating of the device.