Usually, you’d want to send some things here in #general to #meta instead — let’s try the opposite today: Was just reading this thread in #CEXED56UR: https://futureofcoding.slack.com/archives/CEXED56UR/p1577580388049900 And it made me think… probably because I was just on Twitter and there I read this thread: https://twitter.com/Jonathan_Blow/status/1212857853754478592 We software developers are an interesting bunch.

seemed to work.. fine. Not pretty, not pleasant, but tolerable.

What makes us so much more tolerant towards weak design than the rest of the world? Why do we value features more than experience? And do you see this as a problem at all or is this just… fine?

I'd say that we have a high tolerance for complexity because we really enjoy solving puzzles.

It's not just software. I have a collection of screwdrivers that work fine, but aren't pretty or pleasant. Same with my collection of milk crates, and my winter boots, and my french horn, and my cans of tomato paste. Many things in my life aren't as nice as they rightfully should be, but I have them in my life for lack of a better option, all factors considered. Every day is a thousand tiny disappointments because things are finite, and wear out, and don't quite fit, and are constrained by physics or finances. Every new object that enters my life is a new set of joys and disappointments, because perfection is elusive. I would not say that we tech folk are more tolerant of weak design. I would say that our greater insight into software will make us more tolerant of some things (like bugs with workarounds) and less tolerant of others (like storing passwords in plain text).

The thing about the Jonathan Blow comment that bugs me is that, while we certain could design electric cars that are simple, reliable and have few parts, what we are actually getting is "software defined" electric cars where the engine, brakes, steering, etc are all controlled by million of lines of code that can't be fully understood or debugged, and that software is also connected directly to the internet. I have concerns about this.

I had an interesting argument the other day with 2 engineers in this group, who happen to work in automotive real time systems. I suggested that having a pair of central computers that run all the systems would be safer than having 27 different computer systems in a car (Tesla has around that number of computer chips i understand). they were vehement, to the point of anger for suggesting that type of architecture. They insisted that having the braking system on its own machine was safer, because that way a failure in the combustion computer won't affect the braking. However, they were wrong, as the probability of failure increases as you add independent systems. If you have a 1 out of 1000 chance of a catastrophic failure in a single lightbulb, and you have 100 lightbulbs, the probability of a failure in at least 1 of them is almost 10%...so you are better off having only 3 computers, and running all the systems off of the vote of the majority. that is how they do it in spacecraft when they want things to work for 30 years without repair. My guess is that they are worried about performance sagging at critical times with all these different processes. But still, the automotive business is cheap, and they typically have no redundancy on their critical sensors and systems. really not a great way to operate, and when the chips go out of production these cars will be unrepairable. Junkyards will be very busy serving the electrical car era.

I'll note that in spite of all the complexity, the gatekeeping and 'puzzle fondness', software is eating the world. It's not just tech folk that put up with all this but also the users. Maybe the benefits outweight the costs and that's all that's all that's needed for adoption and growth? I mean Gdocs may be clunky and a bit buggy, but still beats paper in many dimensions? Sometimes I wonder if creating something better will just get us to another edge of complexity where we can do a lot more with our systems but quality wise are still in the same place? E.g. we couldn't build the current world using assembly language. Compilers and HLLs give us vast leverage. Most programs we would have written or imagined in asm, are probably trivial to write cleanly and correctly in HLLs. But that's not what we're writing anymore, we're just creating incredibly larger systems.

I'd say software is eating the world in exactly the same way that cars did since the 1950s. It's what Ivan Illich calls a "radical monopoly": a technology so invasive that it has eliminated alternatives not only from the market, but even from our imagination. We don't consciously choose Gdocs over paper, we choose Gdocs over other software without even considering communication not mediated by computers.

@Edward de Jong / Beads Project It sounds like you were thinking of something different from what those two engineers were likely talking about. They were probably talking about the CAN Bus systems in the car. CAN Bus is the protocol that computerized subsystems use to communicate, with each subsystem being a node on the bus. Each node is responsible for a particular physically independent slice of functionality in the vehicle (eg: braking, climate, lights, transmission, steering, etc), and all nodes communicate via the universal CAN Bus protocol — that should smack of not only Unix and the internet, but also and especially of Erlang. In vehicles, similarly to Erlang, you want to be able to maximally continue operation in the event of catastrophic, and typically physical, failure of any nodes or the network itself — things like cables being cut or a liquid being spilled on one of your chips or contacts corroding or electronics overheating or desoldering — because that might happen while you're speeding down the highway or driving up the side of a mountain. You want independent and redundant pieces that can, if needed and as much as possible, operate with a modicum of functionality in the absence of part or all of the network. Nodes or connections will fail, and graceless failure can be fatal. If you have a "host controller" (that's the term from the automotive industry, IIRC) computer sitting at the center coordinating all your subsystem nodes — whether it's a single decision-maker or a quorum — then your whole system has a particularly large single point of failure. For instance, in the event of a failure that causes a network partition with the host controller on one side, the nodes on the other side are either useless or need to fall back to totally independent operation. With CAN Bus (like Erlang, like web services, etc), if you have a network partition, the components on each side can continue to communicate with the other components they can still see to do a better job of the things that they can individually and mutually do in the absence of the missing nodes. The automotive industry (and other industries that use CAN Bus) have previously used other options, like wiring all nodes together point-to-point, or using a host controller, and to the best of my knowledge they settled on the CAN Bus approach specifically because it provided the greatest reliability during operation.

Side note, when discussing something with experts in a domain that's not my own, and I hear something that seems counterintuitive to me, my first step is to try and understand why it's the way that it is. Hearing something counterintuitive (especially from experts) is often a giant clue that there's something interesting to learn! And in my observation the smartest people tend to take a position of curiosity (and I think that's not an accident, since curiosity is how you become smart). Without deep understanding of the problem, concluding that the experts are wrong and my intuition is right (to say nothing of telling them so) would probably be on the very bottom of the list of things to do— not the least because I've been on the other side, and I know how often non-experts have the right picture of my own field (and just how "smart" they look when they tell me I've got it all wrong 😉)

To back up a bit, @Ivan Reese:

I would not say that we tech folk are more tolerant of weak design. I would say that our greater insight into software will make us more tolerant of some things (like bugs with workarounds) and less tolerant of others (like storing passwords in plain text).

Tech folks are more tolerant of ambiguity and trade-offs. Lots of good comes from this, but also one large drawback: we gradually lower standards. Or maybe some people would call that "becoming post-modern"..

I was kinda of rambling about this issue back in 2007 with http://theprogrammersparadox.blogspot.com/2007/12/nature-of-simple.html.

@Kartik Agaram that’s true of many disciplines. Law and medicine, for example, satisfice in many areas, and their professionalization protects their practices from disruption. In software, what prevents a heretic from being successful?

Network effects? But yeah, definitely easier here. For now.

Yes, and the immense momentum of industry. But I like this explicitly political framing for FoC efforts.

I have opinions about what's best for end users. No bones about it. I'm working to make them more palatable, but there's certain things I'm just never going to do. Like make the interface completely polished. I'm building the Serenity, not the Enterprise.

Right, a bicycle not an aircraft carrier. And absolutely, you have to believe in your ideas and values. But (hopefully) none of us is in a position to foist them on anyone. So success means learning from the people you want to serve.

Right. But you wanted the political side here 😄 If I decide that my approach is broken I'll subside. I don't mean to make it seem like a small tent. It's not about Mu the project, but Mu the way. The thing I'm doing that I don't see anybody else in this group doing is trying to communicate costs to end users and occasionally saying, "this feature isn't worth the cost, you shouldn't chase it". We should all look upon anything reassuringly hermetic with suspicion. What is the curtain hiding, and who's pulling the strings there?

Well I appreciate that humility. Most of us aren’t far enough along with out projects to even have a clear sense of what we’d tell people not to use.