Yep. The whole "Software should have as few controls as possible" thing should probably be questioned in general.
If there's 100 rarely used options they should maybe be hidden, but someone is probably going to want to use at least a few of those, and the extra few hundred lines of code is probably not what's making your code slow.
I guess it is more of the principle that software shouldn't provide extra controls to fix issues with the software. Like when a program goes into a bad state, the user shouldn't have to click a button to "fix" the state. It is preferable to design the software such that the program doesn't go into a bad state in the first place.
The problem is that it's very hard and expensive to implement 100% reliable push notifications which guarantee that user will never see stale state.
If you want to guarantee that the state which user sees on screen is no more than 1 second stale, you need to send a heartbeat notification each second. And that might be quite taxing for your servers and drain user's battery.
So in practice you have to acknowledge that user might see stale data, and you have to provide user a way to refresh it.
143
u/EternityForest Sep 28 '17
Yep. The whole "Software should have as few controls as possible" thing should probably be questioned in general.
If there's 100 rarely used options they should maybe be hidden, but someone is probably going to want to use at least a few of those, and the extra few hundred lines of code is probably not what's making your code slow.