reinventing bureaucracy as a different kind of bureaucracy

why is it that rammers of prog always complain about overcomplicated and wasteful bureaucracy, and when they have an opportuniyu to do something about it inevitably come up with something similarly overcomplicated and wasteful?

take agile, for example. agile was supposed to set us free from all the meetings, charts and table of traditional project management, and yet it resulted in a baroque project management structure of daily stand-ups, bi-weekly planning meetings, kanban boards, backlogs, metrics, TDD, pairing, code reviews and other shit? there's so much bloat and ceremony around those supposedly lightweight approaches that it's hard to seriously consider them as a more dynamic alternative to a traditional approach.

but I'm not just going to shit on agile and other silly ideas from the 90s. take some silly ideas from recent years. I found out that some bydlo has recently invented an automated of assigning contractors to their're are tasks, and he claims that it's a no-bullshit approach where you work as much as you want and don't waste your're are time on anything other than code. great, let's check it out:

https://www.zerocracy.com/policy.html

how great, you can just code! but you just need to find a mentor, understand the reputation system and its relation to pay (as well as 'boost factors', hourly rates, speed bonuses, debts, wallets, fees, micro-vesting), student/mentor status, chatbot commands (lol """""AI"""""), projects, sandbox projects, election rules, what gives cash and what gives points, auto-vacations, project roles, shithub, slack and telegram.

how the fuck is it better than... anything, really? and also, why do people do this? are bureaucracies inevitable? or is the problem with adherence to methodologies: programmers overcomplicate things by thinking of rules for every possible case, even if it would actually be better solved and easier to understand with a simple ad-hoc decision by the manager?

In my office, we have a saying - 'This is as AGILE as Niagara Falls' (get it?)

Working practices needn't be over-thought, unless you wish reinvent yourself as a waterfall.

>why is it that rammers of prog always complain about overcomplicated and wasteful bureaucracy, and when they have an opportuniyu to do something about it inevitably come up with something similarly overcomplicated and wasteful?
You just described Silicon Valley's approach to anything. STEMlords!

Don't let agility grind you down.

Bureaucracies mean job security. Why earn money doing something useful when you can make money with pointless busywork? You won't ever run out of the latter. That this is rampant in programming of all fields is ironic considering the goal of automation is to eliminate jobs, but you can see this cancer spread all over the west. Almost nobody is doing anything any more.

>>5
The Virgin Wage Slavery vs Chad Busywork.

>>2

Haha wageslave tales

Traditional programming is mostly planning. Code monkeys don't like planning. They prefer poking. The Sussman called it programming by poking.

prog is problem solving
difference is you have a bunch of tools you don't know the internals of
a computer and an operating system and a programming language's implementation, and a bunch of libraries and frameworks
but at its core it is problem solving

>>5
this is so true. I'm a security guy but for some bureaucratic reasons that aren't worth dwelling on, I need to check in some amount of code every month. while usually it's not a problem because I'm either writing PoC exploits or expanding my tools and scripts, sometimes we have a slow mont and there's just not enough code. so what I do is take one of the simple exploits or scripts and overcomplicate it to hell, make it take command-line arguments, separate shit into functions and/or classes, replace hardcoded strings with something more "configurable" etc.

that's entirely pointless and I never use those overcomplicated scripts, but I check them in to make the management happy.

reinvent and overcompilcate those dubs!

hardware = truth/functionality/scientifically understandable
software = useful fiction/legalism/interface to functionality

Q: why is software shit?
A: it is the nature of fiction to disappoint

Q: but why, really?
A: it's become more profitable to use the properties of software to restrict users than to empower them. as Plato would say, the professional has distanced
himself from techne and become a businessman

>>10
One of reasons people create "enterprise-class" code is exactly this.