Anything Goes Style

In anything goes style, you code whatever works. You do not question it; if the results appear to be more or less correct when you run it on your machine, you ship it.

Anything goes style is often paired with brute force style. So you get these mega functions of insanely mixed logic that are deeply nested, and the code often does all sorts of bizarre, wasteful, and disorganized things. Generally, it has more bugs, and they are rarely fixed correctly since the logic is convoluted and fragile.

Anything goes style also burns resources like they are free and is a primary driver of bloat. It uses way more memory than it needs, relentlessly beats the disk to no effect, and litters the network with countless useless packets.

Modern hardware hides it, but when you see a lot of it congregating together, it is obvious that it is spending too much time doing useless work. We often see large software packages growing faster on disk than their added features.

The style became more popular with languages like PHP and JavaScript, but it got an epic shot of adrenaline with containers. No longer was it obvious that the code was awful when you can just package up the whole development machine and ship that directly, in all its inherent ugliness.

Anything goes is often the coding style at the root of security failures. The code is so obfuscated it can’t be reviewed, and the containers are opaque. That it isn’t doing its work properly isn’t noticed until it is too late and has already been exploited. A variant is to wire up overly expressive dependencies for simple tasks but not lock them down properly, so the whole thing has more holes than Swiss cheese.

Some people argue that it’s a programmer’s job to toss out their work as quickly as possible. Why spend extra time making sure infrequent things like security breaches don’t happen? This has led to some epic failures and a growing frustration amongst computer users that software is ruining our world. It is the tragic opposite of engineering. Our job is not to create more software, but rather it is to solve people's problems with reliable software.

Other styles include:
https://theprogrammersparadox.blogspot.com/2025/06/brute-force-style.html
https://theprogrammersparadox.blogspot.com/2025/05/house-of-cards-style.html
https://theprogrammersparadox.blogspot.com/2023/04/waterloo-style.html