Six unpopular opinions about software standard development | Hacker News Reader

Six unpopular opinions about software standard development

timdaub.github.io

20 pointstimdaub23 comments

Unpopular opinions:

1) Sometimes it is good with multiple standards so you can choose whatever you want (e.g. databases).

2) Sometimes it is good with enforcing a single standard. There is no value in European countries having different 220V plugs. And definitly no value in multiple 220V standards within a single country.

2b) Often it is much more valuable that everybody use the same standard than having the best standard.

3) The proper selection of #1 or #2 does not happend automatically. Sometimes it does, sometimes we have to force a selection. (Often Government does a good job here, but I assume it is too controversial for HN to praise governments).

I am from Ukraine and sockets for 220V is slightly different in Soviet and Euro standards. In old houses there are still Soviet ones because it is hard to redo, especially because of very often Soviet sockets use to be part of wall without easy way to disassemble and to set a new standard. But Euro standard is so good that it replaced new standard naturally because both being better and having no Soviet spare plugs and sockets.

I shared this real-world story because it slightly contradicts with your message having the 220V metaphor.

I don't think it contradicts because you're upgrading from one standard to another.

You are not selecting to have two standards in a new house. Or if you are building two new houses, you're not building one with Soviet standard and the other house with EU standard.

Your case is more like EU upgrading from Mini-USB to USB-C as the standard plug for mobile phones.

I have no experience with Soviet electrical standards but as a brainwashed American I would assume this is a bit out of an outlier, because the Euro standard is objectively better and the Soviet one is so obviously bad/flawed/worse/whatever, that you don't really have two competing standards; you have the good one that is 100% of new installs/refurbs, and the bad one that only ever gets ripped out.

This is in contrast to e.g. databases where most of them are "good enough" and the decision to use one over the other is much more subjective.

Unpopular opinion: people ranting about one aspect of a topic in relation to a specific issue, should stick to that.

Writing a generic rant against all standards isn’t really productive because makes it hard to take you seriously.

I agree with you and it must be a misunderstanding: I'm pro standardization.

Personally, I would have started with an example where standardization is a problem and talk about when standardization is an impediment to progress. :)

If you set the context first, it directs the discussion. Otherwise your audience is left to put your words in any context they like.

Adding examples later is attempting to redefine the discussion after the reader has set the playing field.

> Email is unencrypted because some value-extracting tech companies are controlling large parts of the infrastructure, and there is a systemic problem with gatekeeping that suppresses innovation.

Huh? I can only assume that the other isn’t referring to S/MIME or PGP, etc., but to encryption of transport and/or storage. Or maybe they are limiting their consideration to web based email?

That assumption is based on decades of PKI experience: unless every message is encrypted and signed, by default, without user action, and somehow (notice the hand waving) users are automatically enrolled in a seamless, invisible, low friction, key management system, encrypted email is just too complicated for most people.

There are so many moving parts, from getting a certificate, be it PGP or X.509 or something else, to having a working email client with encryption, to knowing that everyone else does, to deciding whether or not every email should be cleartext, signed, encrypted, or encrypted and signed.

I’ve taught this stuff and it is surprising how many people think a signed email has some level of confidentiality protection just because it isn’t readable text anymore (clear-signed aside).

The reason that web clients don’t offer encryption or signature is most likely because it is a support nightmare.

We’ve known HOW to do this stuff from a technical perspective for decades. What we have yet to figure out is how to make the UX acceptable or elegant or pleasant or seamless.

With controlled "infrastructure", I was referring to Gmail and other email services of big tech.

Presumably with the web client. There is nothing to prevent sending and receiving encrypted/signed emails to/with a capable MUA using a gmail-based address (I know this because I have done it).

The gap in the market is accessing those emails via the web interface (or native gmail phone apps).

Your implication that they don’t add this capability because it is at odds with their values or what brings them value is at best only partly correct, and the most compelling reason for its being correct is that the support costs for average users - and the risks of having those users make errors and get the security wrong, which is entirely a user error in the current space - is simply too costly for them to gain value from supporting the capability.

In the old days you needed to adhere to standards such as ISO to be able to bid on government contracts. If you weren't standardized then that was a barrier to bidding for a government tender. I was never really aware of how deeply such standardization impacts software development. When the market maker is the US government or Dept. of Defense then you will do what they require or be on the outside.

Fair criticism and just as a disclaimer: I don't work on standardization in big company. Mostly as an individual contributor, so I don't personally value government-door-opening as much as a company would. I doubt I'm representing such sentiment in my article.

That blog post misses nearly all the point of the XKCD comic it is referring to. Having jpeg, and gif, and tga, and other "standard" image formats is a great thing. But deciding to create another standard believing you can get rid of all the other "x" standards is (almost always!) folly. That is the point of the comic. This is an anti-pattern that constantly comes up in software dev and other domains, and it is deeply problematic. Creating standards for new ideas, or new takes on old ideas, is not the issue.

Fair. I agree that sometimes creating a new standard is boiling the ocean.

But my take is less pessimistic. My frame is: If everybody creates new JPG standards, we'd have more innovation and progress (despite potentially having more fragmentation...).

Are you really going to get a whole lot of argument when pointing out that memes lack nuance?

There will always be people who object reflexively to any proposal. You can and should simply ignore them. But be careful not to filter out substantive objections at the same time. Sometimes when someone expresses an objection that makes no sense to you, it's you who isn't understanding something, not them (and, of course, sometimes it's them).

I'm sorry but your comment is now a child of a flagged post and so nobody will read what you and I have to say so it isn't worth pursuing this discussion.

Currently, this article is flagged.

Regardless of whether you agree or not, there is no reason to flag this article, unless you are doing so in order to suppress opinions.

I think the author misunderstood the XKCD—they use it to complain about the idea that standardization=good. But the comic is not pro standardization. It is a criticism of standardization for its own sake.

Reply on news.ycombinator.com