Comment by landryraccoon | Hacker News Reader

Comment by landryraccoon | Hacker News Reader

Parent Full thread

I find this argument very unconvincing.

To use an engineering analogy, if the government were a software application, this is very much like a senior engineer going on a major refactor of a production system, causing huge breaking changes for the sake of "principles", without consulting product, CS or QA. For the sake of argument, lets grant that there's some force to those principles. Is that justification for suddenly breaking a system that was working and causing a massive amount of confusion for downstream users that were blindsided and now have to do massive updates of their own?

Okay, now lets suppose that the same senior engineer was secretly (or perhaps even openly) beating the drum for some feature changes behind the scenes, and nobody liked the features he was proposing. Now after the refactor, it turns out that for "technical reasons" the features now work the way HE wanted them to. When asked, he claims it wasn't a political decision, it was driven purely by engineering concerns, "cleaning up tech debt" and so forth, he claims. Might it seem to you that the refactor was just a smokescreen for just getting the feature changes he wanted into production?

If this engineer was at your company, would you keep them on, or fire them as soon as possible?

Now according to your argument, you view SCOTUS as the engineering team, and Congress as the product team. You're saying that ten years after you release a feature, the technical lead can say "Hey, you remember that spec for those features we released to production 10 years ago? I think we did it wrong, we need to refactor it so it works right. Also that was the old engineering lead, and I never liked them anyway. It'll be a major breaking change, but that shouldn't be an obstacle to doing it right this time. Should we ask Product or the Executive team first? Of course not, we know what we're doing."

> this is very much like a senior engineer going on a major refactor of a production system, causing huge breaking changes for the sake of "principles"

That's what the people with the creative interpretations on the constitution did. This is restoring to a previous commit before that happened.

Would you restore to a decades old previous commit on a system that had been running just fine in production that entire time?

SCOTUS isn't even really the engineering team imho, they're devops. If they're there just to enforce the rules, the rules are set just as much by precedent as by the letter of the law, since precedent is what is already working. They should just keep the system running and have a strong bias for favoring the status quo.

This court isn't "conservative" in the traditional sense; I would call them hyper-reactionary.

"running just fine in production" is your assessment.

The court's job isn't to decide if the system runs well or not. It's to uphold the legal structure which was established long ago, because of the initial belief thaf in the long run a system without checks and balances will fall apart.

Federal branch agencies need clear limits to their power. There are many historical examples of why this matters. Congress failed to create clear limits for the EPA, and the court is telling them they need to do their job. That's the court's job.

I like seeing one branch of government do its job and keep another branch accountable. Nothing prevents Congress from granting them those powers explicitly - except for political will, which is exactly the point (agencies shouldn't be doing things for which there is no political will).

Nothing prevents Congress from granting them those powers explicitly

I think you're correct, but just to play devil's advocate...is it possible that as society get more complex, it prevents them from doing so? It's jarring to hear Congress talk about passing bills before they read them, but in the context of everything the would have to know in an increasingly complex society, it may be a sad fact that don't have the ability to both pragmatically and judiciously create laws.

Thinking in terms of software; it's easy to come up with hard rules for writing "Hello World" programs. But expand it to a space shuttle with hundreds of thousands of lines of codes, the number of interfaces grows so fast that creating centralized hard rules becomes nearly impossible.

This is an argument against large central governments.

If the system gets too large to effectively govern with understandable rules, then will be captured by special interests, which are the groups with the strongest incentives to create / understand these complex rules and use them to their advantage. This is called regulatory capture and the larger and more complex a system is, the more likely it will be captured.

This can be avoided by governing as close to the local level as possible (the subsidiary principle) so that you never have the complexity of governance grow to the point it gets captured.

Unfortunately strong central governments don't like their power being taken from them, and they are more powerful than any political organization within their territory, so in practice you have power move from local to national and rarely the other way around.

I understand your perspective, but disagree.

Central governance is, in some ways, a response to complexity. If you extend the "governing as close to the local level as possible" too far, you risk an unnuanced understanding because the local level can't be an expert on every system they interface with. For example, do you have the knowledge to accurately assess the risk when you take a flight? If you're like most people, you probably don't know enough about aircraft maintenance, or avionics, or pilot training etc. I know libertarians may disagree but don't think a mish-mash of localities helps in this case either, at least not in the short-to-medium term when you risk a lot of bad days before everyone agrees on a set of standards. This is exacerbated because of a lot of cognitive biases regarding how we perceive risk. Particularly with big systems with lots of complicated interfaces, the lowest level of effective governance may start looking an awful lot like a centralized government.

I would argue it could be better improved with fundamentally refocusing politicians attention. When half their time is spent campaigning, it obviously constrains their ability to craft policy.

> Federal branch agencies need clear limits to their power.

Yes, and if Congress wanted to set these limits, they would do so.

Which, in the case of the EPA, they did.

The court looked at the limits, and decided they didn't like them.

> Would you restore to a decades old previous commit on a system that had been running just fine in production that entire time?

So you believe the Supreme Court should not have ruled anti-racemixing laws unconstitutional, because they had been considered valid for 99 years since the passing of the 14th Amendment (which the Court used to justify its decision), whose authors were alive during much of that time, and hadn't mentioned that they've been made unconstitutional by its passing?

Or is it that if the court moves in one direction, that's okay and progress and living constitution. But if it moves back, that's hyper-reactionary and they should just maintain the status quo? In other words, you want a ratchet that only moves in the direction you like, even if it means ignoring the law in favor of the status quo (but only in cases where you like the status quo)?

We're not a software shop, we're a country that has deep, systemic problems with executive overreach and abuse. Analogizing to a company producing banal software trivializes the extent of the problems we're facing and abstracts away a lot of real concerns into fungible "features".

Is that justification for suddenly breaking a system that was working

The fact that West Virginia v. EPA was brought up in the first place indicates that the system was not working, at least for some stakeholders.

Even if the system was working for most stakeholders does not mean it was Constitutional. The Court's job is to determine legality, but they need to wait until a case is brought before them, whether it's immediately or 10 years later. It's due process.

you find a political argument unconvincing so apply a software engineering analogy

I applied it by way of analogy.

If you want a political analogy, politically, there is no "right or wrong". SCOTUS is not motivated by adherence to precedent, they clearly have an ideological agenda.

They are not, for example, legalizing marijuana, on the grounds that the FDA should not have the authority to schedule drugs. They chose to go after environmental regulations because they ideologically prefer capitalist interests over environmental ones. It is brazenly political, as was their overturning of Roe vs Wade.

>They are not, for example, legalizing marijuana, on the grounds that the FDA should not have the authority to schedule drugs

But the FDA DOES have the congressional mandate by law to schedule drugs even details regarding what those schedules are.

The difference here is the EPA does not have the mandated far the reaching authority they are enacting which would fundamentally change the entire economy.

Maybe you played hooky in Civics 101, or maybe not, but your understanding and analogy both require substantial correction.

Fixing this:

If the government were a software application, this is very much like a project led by three senior engineers for a system using a widely agreed upon Design that was flexible, but included boundaries. This consisted of Four major elements: (1) Codified Business Decisions, (2) Execution Environment, that mainly ran the project management, and the security (3) The Business Representatives, who created new Business Decisions, and a (4) User Community who ultimately controlled all of above, and paid all of the bills. The first three major elements regularly jockeyed for control over the software app. Over time, they deviated from the initial Design in ways that favored themselves and made the environment less favorable for the User Community. Business Decisions started to critique, and invent new business decisions out of thin air. Execution Environment tried to take over everything in spite of the agreed-upon Design, and existing Business Decisions. Even the Business Representatives went off the rails to favor the consultants that were treating them to fancy dinners instead of the business units they were sent to represent, and they started to define the future roadmap to include proprietary functionality, written by the consultants. But, the consultants also tried to subvert Codified Business Decisions and Execution Environment.

Over time, the User Community took actions to correct some of the most egregious errors by the Codified Business Decisions senior engineer that violated the original, as-modified Design. He did not receive an engineering change proposal that was funded and vetted by the Business Representatives, nope, he was just a cowboy. Through influence, they were able to impact the hiring of the newest crop of Senior Engineers, and revisit past errors. The new senior engineer in Codified Business Decisions revisited some of the decisions the User community claimed was encroaching. Codified Business Decisions finally stated that would undo what they determined was a bridge too far in a business decision that the Business Representatives had never supported broadly, and had never received agreement. They prioritized it as a fix in the sprint, and then pushed it. The fix came out, and the consultant class declared war. They'd been enriching themselves at the expense of the User Community for a long time. In a related topic, another member of the consultant class was caught by Execution Environment rentacops trying to assassinate a junior member of the Business Decisions Engineering Staff, for a similar decision with which the consultants disagreed. Other consultants declared they would kill off all the junior members of the Business Decisions group.

Reply on news.ycombinator.com