I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise.

I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platforms", meta-problem solving and needlessly complex deployment environments.

Contrast this with my current industry, gaming. Here the problems are real, tangible and hard. Suddenly overcomplication is much less of a problem, because the extra cognitive load becomes too much when your core problem is already hard.

Just as a counterpoint, I've done a little bit of game programming and currently work on a tax reporting system (mostly). Both are full of random shit you have to know for no reason. The game random shit I've had to learn was often tied to very specific platforms at very specific times. The game stuff very often I had to delve into actual math + algos.

The tax reporting system I get bogged down and mired in the literal thousands of edge cases and exceptions due to the interactions of all of the laws, sometimes written maliciously by some political entity, or sometimes some local municipality goes against the federal laws leading to literally impossible scenarios. On top of that you have things like your company booking transactions one way that they shouldn't have and is now too much of a pain to change so it has to get reported differently at the reporting layer (which itself is a problem as to why this wasn't noticed initially). Very often the gov't specs themselves are contradictory.

Here is an example: stocks can sometimes pay debt interest did you know?! That doesn't come up in any of the fixed income documentation I had to read. But right there in some list of bonds the IRS publishes every year are non-bond things. wtf?! So do you fabricate some new type "debt interest paying thing" of which are mostly composed of bonds and once in a while stocks in your data model? Do you keep your data model clean and fabricate an internal bond to represent the debt part of the stock in these cases and link it to the actual stock? You will have to consult with your legal/tax department and realize if you were to misreport this income what would the resultant fines and loss of customer goodwill is (due to higher chance of them being audited, paying more tax etc)? Do you conclude that your internal team cannot keep up with the ever marching and changing tax law (FATCA anyone wtf?!) and outsource this to a tax reporting company? The scope of our tax reporting is nearly unlimited since the US government seeks to capture all of human endeavor. The results of getting this wrong are very real. People get audited and lose money and sue our company and can go under due to litigation costs. In games, if we fuck up, our company goes under and everyone loses their job but I didn't have to worry so much about potentially ruining the jobs of people outside of our company.

This is actual complexity your software will have to deal with no matter your language/platform.

In my, admittedly limited (never AAA), experience with games I always seemed to be bumping up against physics (time, memory, latency/speed of light) but with enterprise apps it's almost always bumping up against the sum total of human stupidity past and present.

I'm not refuting that businesses can be complex, but I am saying that most of the complexity I've seen hasn't been inherent to the business.

I understand, I should have been clearer. My experience has been the opposite. The companies I've worked for had actual complexity to tackle. I guess I got a little defensive because I've encountered "game programmers are gods, everyone else sucks" attitudes before from forums and fellow programmers and projected that onto your response. Sorry.

No worries. The gaming industry has its own set of problems for sure, so I'm not claiming it's inherently better in any way :)

I'm glad to hear if your major challenge in the enterprise was to solve actual problems and produce real value. My journey was mostly learning one over-complicated framework after another, and finally coming to the conclusion that it was mostly for nothing. I was the local Spring expert, but at the same it's biggest critic. The "code", or more accurately the configuration, gets very consise, but you risk ending up with only a handful of people in the building who know how to debug the app properly.

I started coding Java when Sun marketed it as a very pragmatic choice, focusing on "simply writing code". The influence of IBM and the whole JEE movement (including Spring) still looks at the problem of coding from the wrong angle IMO.

Creating a good development environment is not about creating a all-in-one runtime environment or methodology, nor about simplifying the problem space for developers by letting them write plugins to large servers.

It's about establishing a fast RAD cycle and offering a buffet of good libraries, to simplify the writing of code.

Java used to be the language which allowed you to "just program", nowadays the mainstream choices are golang or node. To me it's become very clear that Java is on the wrong track here.

There are an infinite number of distractions as a coder, including Microservices, responsive design, functional purity, patterns etc.

If you managed to duck most of these and end up in a place where you were producing value effectively, you were very lucky judging by my experience :)

Extensive experience writing enterprise apps in many different industries? To me it sounds like you're trying to refute a generality with anecdotal experience. Have you ever worked for a heavily regulated industry like healthcare or insurance? The business logic is heavily tied to the regulations which vary by state/country and can be quite... cumbersome.

That is true. I don't really refute that there are instances of complex rulesets. I've worked in some regulated markets, but not healthcare or insurance.

That said, I stand by the point that most complexity I've seen has come from infrastructure. Because although the rulesets might be complex, the way they are encoded is usually the source of the problem IMO.

For example, if the rules of the business are encoded in such a way that unit testing them is straight-forward, it puts the business at the center.

But when every rule is testable only in a complex deployment, the complexity of the app is no longer tied to the complexity of the business.

And the latter has been more the rule than the exception in my experience.