[nisa]

Complexity kills your product - Overengineering is just one instance of complexity - Technical Debt like having state and data all over the place is another one - I quit my last job and I happily blame this article for convincing me to quit: https://itnext.io/the-origin-of-complexity-8ecb39130fc - coordination causes complexity and this killed me - we had everything not once but twice or more in different places - just one example - it's much more complex but me and my colleagues were grinded between an old codebase that nobody understood anymore and kubernetes, ci, etc.pp on the other side because management sold this without understanding that you need a process and time for digesting and applying the concepts in the team.

[oweiler]

This sounds exactly like the last place where I worked. I quit in anger Not because I don't like Kubernetes but because management sold it as the fixall solution.

[throw10920]

> Complexity kills your product

This is like saying that water is lethal - both are true in the sense that some x (water, complexity) is ok, but too much is bad.

Complexity is an unfortunate (but necessary) side-effect of (1) adding features and (2) optimizing for performance, both of which are critical for building a product.

If you try to remove all complexity from your product, you won't have a product. Instead, you have to try to minimize complexity while still delivering the same set of features and level of performance.

[vanusa]

The basic point is that the default tendency in many environments is to run toward ever-increasing levels complexity -- often without even being aware that this is happening -- rather than be (as I believe one should be) by default always skeptical of added complexity.

If you try to remove all complexity from your product,

This wasn't what the commenter was advocating, of course.

Rather it was an attempt to simplify the basic message of: "Complexity has attendant risks which are too easily ignored -- and which in short enough order, can kill hour product."

[vanusa]

your product

[nisa]

basically I just looked for an excuse to post the link to the article - which is really a great article and describes the problems inherent to software in an - for me at that time - new and fascinating way.

Of course in practice it's always messy and rightly so, but I've learned the hard way that you better don't loose control about your state and data - because that's where the ugly bugs are.

The article is very good. Just ignore my drivel :)

[baby]

I interpret “early over engineering” not as adding complexity necessarily. It could also be about decreasing complexity but by taking too much time. Early on you’re supposed to rush to your MVP and add tech debt, not spend too much time to design something pretty and modular. Later on once you know your company can survive multiple quarters, then you can spend more time refactoring.

[jasfi]

I agree, complexity is the real underlying problem. That is why good frameworks and libraries help so much.

[123pie123]

>That is why good frameworks and libraries help so much.

until they change - again.

[jeffkeen]

Gotta keep up with the updates

[amelius]

My dependencies can't keep up.

[rytcio]

Frameworks and libraries are the cause of complexity, imo

[baby]

It depends, there’s a trade off. At some point things can become very complicated if you don’t abstract them and put them in their own lib or framework.

[toopok4k3]

The less you use external dependencies, more time for you to focus on your own product instead of solving problems updating those dependencies and replacing them.

[d0m3]

Great article, thanks for sharing. I like the vocabulary explanations and the chart that summarizes all. Will share and read again!