To clarify, OS X was descended from NeXTSTEP, which was built on Mach and BSD.

I agree. Sadly, software engineering is not engineering. Nobody, out side of safety critical systems, analyses the program structure and makes valid correctness claims for it as part of their quality process.

Software is at a stage that architecture went through before structural engineering really became widely adopted towards the back end of 19th century.

While we have pretty good tools these days that could do formal verification of our software, the process is incredibly time consuming. Moreover, all formal verification can ever do is show conformity to the specification. The specification can, of course, still be wrong. The move from the informal world of business to the formal specification of a system leaves a lot of room for mistakes.

How does a buyer of software know whether one piece of software is higher quality than another? Is there any real way for them to independently judge the quality of the code in most purchases?

My final thought to reflect on is that acceptable quality is enough quality and for most users that is reached fairly quickly. People will tolerate software that is really quite buggy. Games developers are actually giving us relatively deep insight in to that part of the economics. They still make money shipping games that are basically broken.

This point about game development is quite illuminating I think. The reason that most software is quite buggy is fundamentally an economic question - not an engineering question. Generally speaking, people are not prepared to pay for quality. They want enough quality that the software isn't a false economy - and we as an industry largely supply software of that quality.

It's one of these things I find online, especially talking to Americans, is this desire to believe in any wild conspiracy theory that crosses their mind.

A vast conspiracy within the Democrats to deliberately turn off their own power to hurt Trump's re-election chances is just laughable. Extraordinary claims require extraordinary evidence. Who did it? How? and Why? I'm not convinced your why is good enough.

Between 160,000 dead American and him saying "it is what is" - he doesn't need a giant conspiracy to take him down. He can do that all by himself.

I'm married to a professional masseuse, and can get as much massage as I need. I still go to a chiropractor for neck and shoulder problems.

My thought exactly. It seems kind of pointless to increase speed while increasingly limiting data per month.

I can't imagine a robot replacing me as a self-sufficient homesteader. I'm not going to fire myself, and robots all becoming homesteaders to the point that there are no human homesteaders would be...weird.

Satellite internet access is so shitty. It goes out constantly, doesn't deliver on promised speeds, and has ridiculous data plans. I had one of the largest data plans at 10 GB a month. I had hunted to find the best satellite provider and got Wild Blue. The customer service, ugh, that was the worst. They knew you literally had no other options besides dialup so I would get charged with random shit and have to spend 5 days on the phone trying to get my money back. Eventually I had my internet cut off because they said I downloaded the Matrix (?) and demanded $200 as a settlement offer and I told them to duck off.

Garrett county Maryland, 500 MB, after that throttled to dialup speeds. That is not a typo. Please kill me.

3mbps satellite? I pay $70/month for "10 mbps" which actually gives me about 70 kbps. Only option for me, living at the intersection of buttfuck and nowhere. .5 mbps would be a huge relief. Dialup speeds on the modern Internet suck so much. Fuck you very much, exede satellite Internet.

This, I believe, is the story of EVERY migration. It's not necessarily that older is better, or "they don't make them like they used to", but that software development is a bug-prone and arduous process that you will not get right the first time.

This is absolutely the case. Software projects are still incredibly risky. You only have to read the Standish Group's CHAOS report to see how risky these sorts of projects from a management perspective.

The fact that the system is still there doing it's job means that the original project was one of the lucky ones that made it through to a somewhat successful conclusion. You need a very good reason to run that risk again.

In general, just upgrading your dependencies and tool-chain is probably not a sufficient excuse. You need some other compelling reason.

If your tester is finding 100 bugs a week, you're doing it wrong. Your underlying quality is much too low. It's much more expensive to find a bug by functional testing than by code inspection. This is because all those bugs need to be fixed and retested. This usually requires a rebuild and other ancillary tasks that drive up cost.

Worse, it's usually a geometric progression with this kind of pattern in that for every hour spent bug fixing, there's a ratio of new bugs introduced that have to be removed by the process. This process repeats until the defect count is acceptable. Even with a relatively low co-efficient of bug introduction, the geometric series usually adds 20-30% additional cost to the development.

This comes back to my earlier point on people ignoring published research because they feel they know better. Do you know there's actually properly controlled scientific trials that actually establish the truth of what I'm saying? Why is your thought superior to this research? Why is this research defective?

Code inspections work best when they're formal with clearly defined roles and clear reporting steps. There have been large scale studies done that confirm this. The research fed in to the development of the Cleanroom methodology pioneered at IBM.

The less formal the structure, the less well it works.

One of my big bugbears with software development as a craft is our failure to really learn from experience. There were lots of studies done on the craft from decades ago that cleanly establish these basic principals. We choose to ignore them because developers feel they know better than published research.

The truth is that people suck at writing software. Even the very best developers in an organisation are not as a good a team of lower quality people that inspects their own output. Teams > individuals.

Honestly, it isn't as corporate as it first appears. Once the roles are defined, the work turns to inspecting the source. It takes a few seconds to cover off that part of the meeting and from there the real work begins.

There are other benefits

One is that everyone has read everybody's source. There's none of this "Only Bill knows that piece of code." The whole team knows the code very thoroughly.

Another is that relatively junior people end producing code just as solid as person with 25 years experience. They end up learning a lot on the way. Do not estimate the tremendous power of that.

My teams enjoy the process and they certainly enjoy not getting as many bugs coming back to bite them in the future when the feature is out in production. Once they're done, they tend to be done and are free to move on to the next feature.

The benefits of having a cleaner code base, fewer issues and more accurate delivery times has a huge affect on morale.

I find this example really odd because Linux is built around a process of a huge amount of code review. They do it differently because they're a distributed team but they absolutely have a rigorous code review process.