Every 10% you don’t charge roughly doubles your battery life, scroll down to “The 80% Question”. This applies to Apple batteries, but I suspect most other recent battery are in the same ballpark.
I think your exception model needs to match your problem domain and your solution.
I work on an Inversion of Control system integration framework on top of a herd of business logic passing messages between systems. If I were to do all over again, then I’d have the business logic:
* return success or failure (invalid input)
* throw exception with expectation that it might work in the near future (timeout), with advice on how long to wait to retry,
and how many retries before escalating
* throw exception with expectation that a person needs to check things out (authentication failure)
Unless the business logic catches it, unchecked exceptions are a failure. Discussion about what is what kind of exception is hard, but the business owners usually have strong opinions taking me off the hook.
s/defense/regulated industry/ I found a bug in my company’s software product once. The code was using the user’s display name in a lookup rather than the username. I grabbed a QA engineer, he agreed it was a bug, and he put the wheels in motion. I don’t think that fix ever made it into a release.
Our software was part of the stack that our regulated customers were using to document their compliance. Every year or two, they would audit our development process to insure that untoward code wasn’t slipping into the release. Getting the fix into a release would have required that the bug be prioritized, fixed and qa’ed. Never became important enough. It burned me at first, but I’m not sure it was the wrong outcome.
I have a similar situation and I think that you might be able to have 1 standard account and 5 basic accounts in this situation. Depending on what capabilities the other 5 people need.
IMO, the core principle of agile is “early feedback means smaller corrective action”. Everything else is just process to achieve that without running afoul of the evil twin “noisy feedback means constant corrections hunting for the solution.”
Agile goes wrong when you don’t get and use good feedback.
You do upfront planning and design, but you only do enough to establish your general course of action. Because good feedback requires context about your goals. If you don’t care where you’re going, then any direction will get you there.
https://randsinrepose.com/guides/apple-charging/apple-chargi...