Create an entity with a mandate to build and the funds to make it solvent. Basic and dignified shelter that enables all the other economic activity does not need to be a profit center.
This is possible but requires lots of money and oversight. I have never heard about scheme like that that replaced private investors. But as a way to offset some RC problems it could probably work.
- inelastic means the demand is more or less independet of the price; you can't "just stop renting & living" if prices are going up, your options to bypass are highly limited -> therefore its called >inelastic<
We are not talking about economic theory. We are talking about house prices. Time after time it has been seen that free-enough market can lower the prices to affordable levels.
Emitting correct XHTML was not that hard. The biggest problem was that browsers supported plugins that could corrupt whole page. If you created XHTML webpage you had to handle bug reports caused by poorly written plugins.
I have opposite experience. Consistency is commonly enforced in bigger corporations while it's value is not that high (often negative). Lots of strategies/patterns promoted and blindly followed without a brief reflection that maybe this is a bad solution for certain problems. TDD, onion/hexagonal architecture, SPA, React, etc.
"In large codebases, consistency is more important than “good design”" - this is completely opposite from my experience. There is some value in consistency within single module but consistency in a large codebase is a big mistake (unless in extremely rare case that code base consists entirely of very similar modules).
Modules with different requirements should not have single consistent codebase. Testing strategy, application architecture, even naming should be different across different modules.
People using it wrong. It definitely should not be that popular. 95% of times when I see it I consider it a tech debt.
You should be using it in rare cases when you want to verify very complex code that needs to be working with strict requirements (like calling order is specified, or some calls cannot be made during execution of the method).
Usually it is used for pointless unit tests of simple intermediary layers to test if call is delegated correctly to deeper layer. Those tests usually have negative value (they test very little but make any modification much harder).
In the same post you are arguing for and against "slippery slope".
Either it is possible to easy change law to make it worse ("slippery slope" is valid objection) or changing law is "much harder than doing nothing"("slippery slope" is a fallacy).
reply