Ask HN: Is Accidental Complexity Growing Faster Than Essential Complexity?

Your simple example of associating a Customer/Client to an Address is a great one - it could be that a really simply approach is required, or you may actually need the powerful features around such things that some high end ERPs support.

In a previous job I spent a lot of time trying to get a shared understanding of what "customer" actually meant (this was initiated by realizing that the Customer Loss Ratios that execs wanted were really nonsense). This eventually turned out to be a non-trivial problem.

OOP is definitely not dying down - outside of the startup bubble it's still the predominant way code gets written. Silicon Valley may be building everything in Scala and Haskell these days but the rest of the world is still built in Java, PHP and C#.

I have noticed several developers deliberately introduce accidental complexity for the sake of job security. Just to make it really really hard for a new person to do any thing with it , they create a hostage situation where you have to do a full gut of his or her work and redo it. This is more evident in a situation where the teams are geographically distributed and the main team (typically in USA) feels insecure that their jobs are going to India or some other country where software maintenance is cheaper. The problem of accidental complexity is very serious for large enterprise software companies who have aging products typically on a Microsoft stack so those engineers who have spent a decade coding and maintaining it tend to be happy with a crooked way(hacks and workarounds - Undocumented of course) of doing things which gives them an unfair advantage. To conclude; accidental complexity is a political tool introduced by developers deliberately of reasons best known only to them

In retrospect the 1990s components craze feels rather modest compared to what's happening now though, even if you allow for stupid ideas like CORBA IDL which hardly anyone ever used.

Right now it feels like every single tiny aspect of devops or JavaScript compilation/bundling or UI layouting alone has become more convoluted than the entire 1990s software stack.

I realize that we are doing a lot more with software now. But comparing only stuff that we used to do back then as well, like creating line of business applications, analysing some data, or create single user productivity apps, I can only shake my head in disbelief at the incredible loss of productivity.

I believe much of it is driven by a desire to architect every little app as if it had to scale to Facebook or Google size tomorrow, use Web technology for tasks that it is completely unsuitable for, and define "right tool for the job" in such a granular fashion that we end up using at least three database systems, three programming languages and scores of other distributed thingies in every single project. Just look at those "our tech stack" posts that come up frequently. It's insane every single time.

Now it's microservices. What used to be components with well defined interfaces sending SQL to an RDBMS in the 1990s has become a swarm OS processes with networking, service discovery and HA infrastructure in between. To keep it running you need some sort of cat herding devops and monitoring system. The possible failure states are beyond the capacity of human cognition.

But it makes total sense if you're a huge corporation that has an entire team working on each of those services. For Amazon it could indeed reduce coordination effort, increase accountability and make the system easier to scale. For a team of 5 or 10 people it's pure insanity to put a network between two "services" that don't absolutely have to scale independently.

We're scaling out everything instead of scaling up, even though scaling up is hugely more efficient up to a scale that 99% of all projects never grow into. In some cases (particularly in data analysis), we're paying 60% margins to cloud hosting companies for clusters that could be replaced by a single laptop using a simpler architecture.

The Web is such a great thing for all the new things it enables that we simply couldn't do at all in the early 1990s. But I really have to ROFL every time someone says "right tool for the job" and then goes on to layout a data entry form using CSS.

Here's my prediction: We're going see clusters of AIs running on top of AWS GPUs to optimize line of business apps for AWS pricing structures that no human being is able to fully grasp any more. And all of it will be set up by highly paid consultants sold by armies of salespeople.

Here we have an explanation for the productivity conundrum that has economists scratching their heads. So much more sophisticated technology and hardly any productivity growth. How come?

I use an ORM with a popular web framework (Eloquent/Laravel) in the PHP space.

What I've always done is use the Eloquent AR approach for simple stuff where it fits well but actual complex querying is done with 'raw' PDO/SQL since frankly writing complex compound queries using the ORM is more wordy and less understandable.