Hacker News Reader

Comment by citation_please | Hacker News Reader

Ah, when bullshit jobs come up, sometimes the measure is "if this person disappeared, how long would it take for the world to notice?". This article is interesting to me because it applies a slight modification, "if this task was eliminated, would systems be more efficient?".

In some ways this is a good question to ask, but much like a statement in legacy code, it's sometimes unclear why a rule exists until after you remove it, and then it's too late.

If only there were unit tests for real-life bureaucracy...

View on HN

> In some ways this is a good question to ask, but much like a statement in legacy code, it's sometimes unclear why a rule exists until after you remove it, and then it's too late.

The term for this, in case anyone is curious, is Chesterton's Fence.

> In the matter of reforming things, as distinct from deforming them, there is one plain and simple principle; a principle which will probably be called a paradox. There exists in such a case a certain institution or law; let us say, for the sake of simplicity, a fence or gate erected across a road. The more modern type of reformer goes gaily up to it and says, "I don't see the use of this; let us clear it away." To which the more intelligent type of reformer will do well to answer: "If you don't see the use of it, I certainly won't let you clear it away. Go away and think. Then, when you can come back and tell me that you do see the use of it, I may allow you to destroy it."

- G.K. Chesterton.

> If only there were unit tests for real-life bureaucracy...

Not called unit tests but we have something similar here in Norway:

- 5 or more weeks of mandatory holidays. (both you and your boss get trouble if you don't use it.)

- maternity/paternity leave (more than a year combined IIRC, and while it won't land an individual in hot water legally, -everyone including your boss expects you to take advantage of it. Oh and it might land the company in hot water if they prevent anyone from using it which might explain why even the company often actively encourage it.)

It works mostly the same:

- like unit tests it verifies that the organization works, including edge cases like "what if half the company is away for two weeks at the same time". (The last point is encouraged by design it seems by specifying that at least two of the weeks should be in the summer.)

- like unit tests it might seem like a giant waste but turns out to be useful in the long run.

Ah, I really appreciate that you've made that connection. Given the current state of politics in the US, I'm afraid if I ever bring it up it'll be perceived as a gimmicky talking point for expanding socialist policies, but literally every engineer (or someone who's tinkered with something) knows that removing components from a system is an effective method for testing its robustness. Even more so, the worst time to figure out that your system is not robust is the exact moment when you need it to be robust.

> 5 or more weeks of mandatory holidays.

Impossible. Our handsomest politicians assure us that even 2 weeks vacation is pushing the bounds of outright societal collapse!

That's another similarity, I guess.

"We struggle to deliver the features we promised and you say we should create test code as well?"

Honestly I think one of the best ways to find this out is to have people regularly take annual leave, you get a chance to see what they were doing from a different angle when they are not there. Making people take this leave is a really good way to fight presenteeism as well.

sure, you can build a rube goldberg machine, and removing any of the parts might break it. this still doesn't mean the machine is efficient or makes much sense. adding a piece you usually also create interdependencies, which lead to adding even more pieces later. it's not about something breaking, it's about something being already broken in its current state, and priorities (I understand your point, just adding this as a thought)

>>if this task was eliminated, would systems be more efficient?

The thing is those people who designed the systems designed it to make their jobs relevant in it.

Which is why most companies fail to turn around. You can't use the management to fire the management. They are always going to come up some cause for the problem, which excludes them.

Reminds me of a story I read here a while ago - about someone in military being overwhelmed with required reports, who eventually decided they'll stop submitting all reports for a while, and wait until complaints come, in order to determine which reports actually serve a purpose.

It seems, for lack of unit tests, real-life almost never removes code from bureaucracies, and achieves efficiency only by replacing the whole organization.

By the way, I think this is why communism failed. I don't think their error was for companies to be state-owned. The problem was that, in the pursuit of efficiency, they merged all companies in a sector into one combine, thus making it impossible to replace (today we would say "too big to fail").

Maybe the communist/socialist bloc would've been more successful if they had retained multiple state-owned corporations in each sector and allowed for competition between them.

Disclaimer: I was born in 1989, so everything I know about communist/socialist economy, I know from books or from talking to my parents.

You might like to read Red Plenty. The problem isn't the size of the companies as such, it's the notion of planning the economy.

If you allow multiple corporations but oblige them to follow the same plans, that does nothing to address the problem. If you allow the corporations to compete in a market economy then, well, you have a market economy.

> If only there were unit tests for real-life bureaucracy...

Or for legacy code.

Reply on news.ycombinator.com