Hacker News Reader

Comment by randiantech | Hacker News Reader

Funny, that "if one created, two removed" was a law imposed by a Principal Software Architect to me and my team regarding apps and apis as part of a rationalization program. "If you create this new API, make sure to remove at least two". I have to say, after two years there, that helped a lot to reduce redundancy and complexity. But well, apps and api are not the same of public policies... who knows.

View on HN

But "aim for simplicity" is a good enough rule by itself, which isn't further enhanced by some "2 for 1" heuristic.

On top of that, "regulation count" is not a natural category, since one regulation can specify an arbitrary number of things. If you replace A) No smoking and B) no littering with C) No smoking or littering, have you changed anything substantive? You have not.

Regulation complexity, of course, is a natural category, but it's hard to measure before the fact and doesn't lend itself to easily-applied "follow for a guaranteed reduction" rules.

The difference is that you operate in a cooperative environment(well, most of the time) within your team. The president operates in an antagonistic environment by default - even if Congress is controlled by the same party, the two sides of government(executive/legislative) are supposed to keep each other in balance.

I otherwise agree that the measure is too simple.

Yes and more specifically Washington DC, the home of the regulators, voted 92% for Hillary. So Trump needs very hard rules that aren't open to interpretation AT ALL to have any chance of them actually working.

> Yes and more specifically Washington DC, the home of the regulators, voted 92% for Hillary.

Washington D.C. may be where regulators work (though some of that is outside the District), but regulators are a very small share of the population. The vote in D.C. has little to do with regulators (it has a lot more to do with race, but even saying it was solely about that would be oversimplifying.)

In my mind, refactoring public policy is going to be like refactoring business processes in enterprise code.

The perception is that all these "horrible" duplications and inefficiencies exist.

The reality is that the duplications are actually slightly different business cases that are are difficult or impossible to generalize (it was easier to copy/mutate) and that seemingly irrelevant code has potentially far reaching and damaging consequences (oh, that was important?)

The essential problem is that we look at these individual lines of code instead of realizing that they grew as part of a dynamic system.

Refactoring code isn't a good analogy.

Try refactoring DNA.

It becomes quite tragic (or hilarious) when teams try to simplify such systems and instead end up breaking lots of business process that was ugly, but worked.

DNA/evolution is orders of magnitude more messy than that, but it gets things done more safely and efficiently than some refactoring efforts I've seen.

nice way to get on a slippery slope towards "eval()".

"Read My Lips: no new APIs!"

I don't get it, doesn't that mean that eventually you have to have tend toward zero api endpoints?

APIs is a weird unit of complexity. Is 1 API more mental overhead than 12 APIs? It's hard to say.

The goal isn't like APIs: to preserve efficacy with a smaller set of tools. The goal is to literally make the government less capable of leading on things like healthcare reform and climate change.

Check who the Trump campaign says is going to be leading the switchover of the EPA. I think I know where most of the slashed regulations are going to come from.

At some point you have to stop cutting. You can't go thus forever.

"If this rule needs to be broken, then bring me a proposal for why" is a good addition. The idea should be to swap the default to less-complexity rather than more-complexity. If more is less, then it should be possible to write a succinct justification for it.

The US code is 22 million words. [1] is a good visualization of it. I'd wager there are tons of redundancies that could be refactored. That being said, I'd also wager that careful refactoring is not on DJT's mind. More slash-and-burn the parts he doesn't like.

[1] https://twitter.com/harlanyu/status/165184504527462400/photo...

The US Code is law, not regulation, and so is completely irrelevant here. What you want to cite is the Code of Federal Regulations, which is much larger than the U.S. Code.

Of course you provide no reason at all except an unsupported assumption to believe that the size of the completely wrong thing that you cite is an indicator of unnecessary complexity, and the fact that you cite the completely wrong thing is a pretty good sign that you have zero knowledge of the domain from which to form a judgement.

I spoke in generalities. You are absolutely correct. I have no claim to being an expert or even a layman. What I do know is that once a description of any thing exceeds a certain threshold, there are bound to be redundancies. Think of it in terms of codebases for large softwares. The Linux kernel is approaching 20 MLoCs. I'd wager heavily on there being a different architecture delivering the same functionality with less code to describe it. Proving it would be a tremendously hard task, far outweighing any gain from such a bet.

Reply on news.ycombinator.com