I want software to be:

Robust => designed to accomodate all known edge cases

Reliable => operable for an extended period of time under expected conditions without failures

Stable => does not change in incompatible or unexpected ways over time; "if it works today it can be expected to work tomorrow"

Simple => including only as many moving parts as is required to meet the other three goals

@sir While you're wishing why not wish for two trillion dollars?

@sir what do you call "fail gracefully in unforeseen edge cases" then?

@wolf480pl if they're not foreseen they cannot be planned for

@sir i guess it depends on whether "I don't think it's possible for this thing to $become_bad, but even if it does, we have $defense_in_depth"

oh, right...
Defense in deph.
Thank you.

@wolf480pl @sir We can defend against known unknowns, only unknown unknowns are out of reach. 🙂

sircmpwn's 4 rules of software engineering 

@sir merge robust/reliable to make this the RSS rule pls.

@sir if it accommodates all edge cases it's not simple. 1 and 4 seem mutually exclusive.
gnu software is a living example of that by your own attestation none else:

Working on some friends' projects and seeing how they approach things made me realise that.. something so simple it's hackable and customizable according to each client's edge case sounds more attractive than something that can handle all clients' needs. Maybe I'm not looking at things from a sole vendor business pov.

@hyphen features and edge cases are not the same thing. What I mean when I say this is that it accounts for all edge cases within the constraints it's defined to support; for example, handling rather than ignoring errors, predicting and gracefully dealing with unexpected inputs, etc.

@sir and if a client approached you with a bug that requires substantially more complex handling from your side, but the edge case is specific to that client (handling nonstandard text encoding for example?)
Do you see that as a feature as opposed to edge case? It technically makes your software less robust.

@hyphen I don't have that kind of relationship with my clients. I would push back and fix their non-standard inputs

@sir Just saw your blog post revisiting this. The one thing I'd mention is that complex and complicated are very different things. I once read a generic motorcycle repair guide that made the argument that complex systems are relatively easy to diagnose and repair, because despite having many moving parts, each subsystem does a specialized thing, so the symptom itself narrows down which subsystem is having an issue. Whereas a complicated system is too interrelated for such simple diagnostics to work.

We use the terms interchangeably, but really any sufficiently large software project lives or dies based on how well the complexity is managed and kept from becoming complicated.
Sign in to participate in the conversation

The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!