4 ms·
I'm not sure I fully agree. For example > Hydra must be stable. It should never crash It's clearly better to have an app that never crashes than an equivalent
by prof_hobart 12y ago
I'm not sure I fully agree. For example
> Hydra must be stable. It should never crash
It's clearly better to have an app that never crashes than an equivalent one that crashes all the time.
However, making sure that your app is 100% crash-free isn't a zero cost thing. It takes time and effort to (often, a lot of both) to get to a completely crash-free app, meaning that the app either costs more, takes longer, or has to compromise on features - or possibly all three. In some case, that trade off is clearly going to be worth it - I'd rather a self-driving car took 10 years longer to develop than have one that rebooted itself twice a day, but in others I'm fine living with the occasional crash if it means cheaper or more feature-rich applications.
- sitkack 12y agoFor a window manager, crashing is kinda a pain depending how it restarts. Maybe another way to state the implicit goal would be > Hydra must gracefully and rapidly restart should it crash w/o losing any user data. And then maybe it could do this be serializing state into a sqlite or redis instance. We always to be careful of muddling the goal and the mechanism.
- prof_hobart 12y agoI agree. Like I say, there are some instances where zero crashes is absolutely the right goal. It may not be absolutely mandatory for a window manager (in the way it would be for a self-driving car), but I can understand why someone would want this as a goal for this app. My point was more that I don't think it's a sensible standard for all software. I hear this kind of thing quite regularly, usually by non-technical managers, often in a way that seems to suggest they think bugs are either the result of pure sloppiness, incompetence or downright malice.