11–20 of 68 posts
Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.
Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.
> quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/res…
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
Interesting. Why function calls over events? And is it always applicable?
> And is it always applicable?
No heuristic is always applicable.
Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.
> quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/res…
> I read this as "certain principles must be upheld at any cost" and I agree with that.
But that's you reading things that aren't in the text. And by itself, it's not a good principle either:
- "certain principles" - which principles exactly? Of them, which ones are related to quality?
- "must be upheld at any cost" - any cost? There's few things in life that truly "must be upheld at any cost", and they're in the scope of morality, not software. Even "thou shalt not kill" is full of practical caveats.
Everything in software engineering is negotiable, all principles have a price. The important parts are all in the details: what exact principles we have, how they trade off against each other, what benefits do they bring, how much do they cost, how much is too much. This list doesn't touch any of it.
You continue:
> E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make.
Yes, now we're starting to see a glimpse of something useful - but it's still a bit too vague to work with. Consider:
- What is "health data" under consideration? For example, someone's smartwatch BPM and GPS log, a result of MRI scan, a list of visits at a clinic, and how old they are - these are all "health data", but fall into different qualitative categories, and merit different level of care in handling.
- What is "dealing with"? Storing? Forwarding? Processing? How? Giving access? To whom? Etc.
- What is "securing that database"? Are we talking access controls against the dev team? The company stakeholders? Securing against script kiddies? Securing against Mossad? In which particular way?
You may feel I'm splitting hairs here, but this is reality: quality is always negotiable, and day-to-day negotiations will happen at this level of granularity. Nobody has infinite budget to respond "yes" to any idea that could be presented as "increasing quality" or "increasing security of medical data".
Developing lists of principles and heuristics is of great value - but this list isn't that. The heuristics you want need to account for the reality we live in (including working around organizational dysfunctions and individual cognitive failures). And they need to be formulated in practical terms, or they'll forever be words on paper. Their only job is to help you answer the question, "is it worth it?", every time you consider two options of different quality.
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
Sloppy thinking… new age bullshit… most of it collapses under mild scrutiny. Some of it is okay. I just don’t get, after decades and decades, how our industry continues to tolerate bullshit. Quality is not negotiable? Really? Negotiation is not collaboration? Really? This is not just wrong, it’s almost gaslighting.
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
Interesting. Why function calls over events? And is it always applicable?
Very woolly. I was expecting more concrete things like * Use static types * Use CI and version control * Use schema-based data storage * Prefer function calls to events * Use formal verification if possible etc.
> * Use schema-based data storage Great idea until it isn't. The article is full of bullshit but one thing is very true. We can't predict the future, especially so when we deal with humans and society where stuff changes fast. Strict schemas are more pain than gain here. > * Use formal verification if possible Wonder when F* and the like get mainstream so that "if possible" becomes "almost always".
Earlier quoted context omitted.
> quality is not negotiable? Really? I read this as "certain principles must be upheld at any cost" and I agree with that. E.g. if your project is dealing with people's health data, not securing that database is a cut on quality you just shouldn't make. Or to phrase it the other way around: If your project cannot reach that basic quality level, maybe it should be ended right away, because it clearly lacks funding/res…
The great thing about vague bullshit is that if you squint really hard, there's always a semi-plausible interpretation which makes sense. See also: fortune cookies, horoscopes.