Live data from Hacker News

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

news.ycombinator.com

11–20 of 60 posts

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

#11
post #8

It's always been a problem. Premature optimization may be the root of all evil, yeah, yeah, but that quote is sort of a waste of breath as premature optimization is not that big of a problem. Over engineering is the great disease of the software profession. I suppose premature optimization is one source for it, but more common is premature generalization and excessive levels of abstraction. Other major sources includ…

I'd say overengineering and premature optimization are nearly synonyms.

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

#12
post #11
post #8

It's always been a problem. Premature optimization may be the root of all evil, yeah, yeah, but that quote is sort of a waste of breath as premature optimization is not that big of a problem. Over engineering is the great disease of the software profession. I suppose premature optimization is one source for it, but more common is premature generalization and excessive levels of abstraction. Other major sources includ…

I'd say overengineering and premature optimization are nearly synonyms.

IME over engineering almost always results in far worse performance, like a data stack with 15 layers riddled with n+1 problems instead of some simple sql.

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

#13
post #11
post #8

It's always been a problem. Premature optimization may be the root of all evil, yeah, yeah, but that quote is sort of a waste of breath as premature optimization is not that big of a problem. Over engineering is the great disease of the software profession. I suppose premature optimization is one source for it, but more common is premature generalization and excessive levels of abstraction. Other major sources includ…

I'd say overengineering and premature optimization are nearly synonyms.

They're both bad, of course, but beyond that I'd say they're nearly antonyms. Premature optimization trades structure for performance, overengineering trades performance for structure.

You could argue for equivalence under a broader definition of optimization and engineering, but in the context of software engineering the more specific definitions used above seem to be fairly well established.

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

#14
There have been various improvements in programming that reduce accidental complexity but they don't apply in every area. For example, Ruby on Rails makes it easier to create an MVP, but scaling an application to millions or billions of users will still require working on many layers of "accidental" complexity (since scaling isn't an inherent part of solving the problem). Running applications in the browser also adds "accidental" complexity since certain details of the product now need to be defined in both the browser and the server. Testing can also get more complicated as there are more layers and services interacting with each other. It seems as hardware and software improve, the demands on them increase as well. So we can't just relax and enjoy a world of Essential complexity.

Meanwhile as machine learning gets more advanced, it's able to tackle certain "essential complexity" problems that were supposed to always require hand-coding by a human programmer. So there are trends working in many different directions.

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

#15
I work for a large company in the automotive space. I can say that most of the accidental complexity I see is related to shoe horning solutions into technologies that we happen to have licenses for as opposed to what is the simplest and most robust solution.

The kind of over-engineering for the CV polishing almost always comes from our college hires. It's not really their fault, as I understand the attraction to the shiniest object when your a newb. When their monstrosities are allowed to make it into production, however, is when you have a dev manager that doesn't really understand software engineering.

For my part, I used to scream from the mountain tops that we were over-engineering everything, but now I just let them fuck shit up cause I'm tired of trying to save people from themselves.

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

#16
The software field is still very young, and there's lots of things we haven't explored yet. A great example of this exploration is the ongoing evolution of javascript from simple scripts to SPAs and a universal compile target. It seems like a lot of effort is being wasted (because it is), but it's similar to startups in the economy. Most efforts fail, but enough succeed that we end up in a better position overall.

The field may hit a point where there's an obvious standard way to build things, (e.g. most houses in the US are wood-framed with drywall because it's cheap an durable enough for most use cases), but this won't happen for a long time. We've had thousands of years to figure out how to build houses and roads, but software really only started in the second half of the last century.

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

#17
It is easy to look at this from a functional and practical standpoint, take any program in your stack, and look at what it does vs what you need it to do.

There is a parallel to this where people were trying to where people write c++ programs in visual studio realize they often can do so without needing the microsoft visual studio runtime and its routines and their program drops from 68k to 2k and a dash of code to bring back what is missing in most cases, if it is even needed. https://hero.handmade.network/forums/code-discussion/t/94

I love looking at things and thinking about this, people in this field often find themselves over-implementing(or using software that is a source of over-implementation), setting up a tremendous amount of foundation to get a little thing done, getting carried away, and finding out it got too involved and over-engineered when there is a tight and simple solution that matches exactly what is needed.

Of course there are situations where microservices are still needed: https://semaphoreci.com/blog/2017/03/21/cracking-monolith-fo... Everything should be thought out and joining the latest craze isn't necessary. If you really need it, you will find yourself looking for or implementing the solution, regardless of what it is currently called, microservices have been around in one form or another before the hype, and used as needed when needed, instead of getting being used to wax a resume.

Your accidental vs essential comparison has real world monetary consequences. There are many examples that while it might take 2-3 months to stop and think and analyze what is going on instead of adding to the pile, you can save 100k-300k a month for even smaller scale deployments.

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

#18
post #3

In regards to the SPAs, what exactly is the alternative? In my mind you have two possibilities: 1. The most ideal is to "pick the right solution for the problem." Meaning, you will analyze the problem and do the right thing, e.g. content mainly? server side rendering. web application? SPA. 2. Do what you know, consistently. In many cases, this means using an SPA basically all of the time, whether or not it's necessar…

Does isomorphic Javascript count? Example- Meteor js.

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

#19
post #4

Can you please cite some examples of this accidental complexity? I'm very curious to hear, if for nothing else than to avoid it if I agree that it's indeed accidental. I do agree that because of the "GitHub resume" phenomenon, lots of devs are engaging in the type of engineering you describe.

OP mentions line of business apps. I may be presumptuous but that to me says (broadly) data entry forms and reporting.

Anything beyond HTML forms, a SQL database, and maybe a bit of Javascript and CSS is likely to be more complexity than you need for something like this.

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

#20
I honestly don't think it's any worse than it has been before. Back in my youth it was "components". If you can encapsulate functionality, then you should be able to compose it like tinker toys. So let's build these "reusable" components which act like black boxes. We'll nail up the API to the wall, and use some kind of versioning scheme to ensure that it's always backwards compatible. We can even build frameworks that standardise the communication between these black boxes and provide language agnostic object representations. Hell, we can even build database interfaces around that concept and pass business domain objects back and forth directly. And we can hide the complexity of the object-relation mapping in another framework.

Yeah, that will simplify everything :-). It only looks shiny because the people doing it weren't around in the 90's to get sick of it the first time around. Ah... who am I kidding? 4GLs have been around since the 70's... :-P

Post reply on HN