[fridif]

Agreed, but it never should have been this complex in the first place :)

[tacker2000]

Of course, but i cant imagine any non trivial project not to be complex.

A lot stuff is built without knowing what will come after, so often you will have layers upon layers that need to get dug through. Thats just how software will always be…

I took weeks or even months to understand how the Magento 2 (a php ecommerce framework) codebase works, probably one of the most complex codebases ive seen personally to date.

[pm90]

I wonder if its possible to avoid code that is meant to represent real-world business logic from being too complex. In most situations, the requirements of a business are constantly changing and writing code that can express that logic without blowing up in complexity is a really difficult problem.

[zimpenfish]

> I wonder if its possible to avoid code that is meant to represent real-world business logic from being too complex.

Yes. But only for the first couple of hours until someone who {missed the meeting, forgot something, didn't check, etc.} comes along with changes.

(Alas, this happened to me over the last two weeks and now the pristine simple logic is a fudged mess.)

[fridif]

I think this is an argument for less developers on a project, or at least more services owned by less developers.

[TeMPOraL]

It's not where complexity lies anyway. The complexity is in the glue code - the layers upon layers of indirection and endless repackaging of the same data. This is where you need all the "jump to definition"/xref functionality, and it's hardly enough.