moriarty-s3a

This isn't new and your example is a good one. Craftsman tools have always been cheaply made with poor metallurgy. They got by with the lifetime warranty because they marketed themselves at consumers who don't rely on their tools and don't use them very often. At least as far back as the 1950s and 1960s, people whose job depended on their tools wouldn't touch Craftsman.

This is completely cultural. I had a manager that I didn't meet in person for over a year and he was constantly sharing stuff like this with me, frequently multiple times a day. As the sibling points out, if you aren't speaking with your manager weekly, or really almost daily, then something is very wrong.

It's a tradeoff, though. For 99% of LOB applications the odd details of specific database implementations are irrelevant and can be ignored by even a team of mediocre developers. Most businesses are mostly interested in selling 5-10x the number of licenses for 1.1x the cost. (Or, like the sibling comment pointed out for 0.9x the cost because you can usually ignore much of the annoying boilerplate) Performance frequently is more than "good enough" and in the 1% case where it isn't, most ORMs will let you write custom SQL (or, you can always write it outside the ORM). Sometimes the best and cheapest solution to performance problems is to simply throw more hardware at it. IME, most developers are terrible at writing queries with or without an ORM.

There are certainly use cases where ORMs are not appropriate at all but the ability to evaluate your situation and recognize the tools that are appropriate and those that are not is an important skill in the software industry in general and is not limited to ORMs.

The main point of accepting returns is to reduce the cognitive overhead and friction of a potential customer's purchasing decision and make them more likely to spend money with you right now. If a retailer doesn't accept returns then potential customers are more likely to shop around for price or selection and become less likely to buy from you at all, and if they do buy from you, it will likely be later, thus costing them some cash flow. Accepting returns makes people buy more stuff and buy it earlier than they would otherwise. And they are more likely to buy it from you specifically.

The primary problem in retail generally isn't revenue or margin, it is cash flow. Creating additional customers or even encouraging customers to purchase sooner than they otherwise would have is a huge win.

I have seen a few environments like that and they can be just as corrosive. I have seen middle school kids that were great artists or writers or musicians told that they were failures at life because they weren't one of the 15 best math students in their school.

I have worked or consulted for a few that went too far the other way and it wasn't that great either. If the company is too loyal, then it can create a corrosive environment because good employees sometimes leave for reasons unrelated to the employee-business relationship, family, retirement, health, etc. The bad ones seem to never leave, though.

Honestly, I would rather work somewhere that is willing to get rid of useless and/or corrosive employees than somewhere that refuses to do so out of misguided loyalty.

It isn't that they have no way of knowing, it just isn't worth the tech's time (in their mind) to validate the status of every connection. If they are like most other telecoms, they would have to manually cross reference date from multiple applications.

This used to be the case in the US after the Telecom Act of 1996. However, the FCC decided on their own to give the ILECs a grace period of a year to implement LLU and then kept extending the grace period. After the dot com bust and the following recession in the early 2000s, most of the CLECs went out of business and Congress gave up and removed that requirement in 2006.

The state PUCs didn't do much enforcement either, but the FCC deciding not to enforce the law killed it.

Trucking deregulation occurred between 1978-1980 during the Carter administration.

Plus, the way it was regulated makes modern regulatory capture look consumer friendly. If you wanted to start a trucking company, you had to submit a business plan with a list of committed customers and already set in stone pricing. The Feds would literally hand your plan to everyone with a route in the region, give them a few months to review it and then your potential competitors got to vote on whether you should be allowed to operate that route. Predictably, it was basically just outsourced sales for the exiting companies.

Detroit's mismanagement goes back long before 1967. It goes back at least to the 1920s and very likely much farther than that. The success of the auto industry in the area just papered over those problems for a long time.

Don't bother. It is many times larger and slower than any of the frameworks listed. Their code is also broken in "interesting" ways and there are lots of undocumented and semi-documented gotchas.

It got enterprise traction because they were early to the game and promised MVC. They were pretty good for a while, but the other frameworks have passed them by.