I don't think anyone will argue that joe working for IBM has the interested of IBM in mind the same way bil, co-founder of StartupX has the interested of StartupX in mind.
Challenge accepted. Software engineers are a strange, nerdy bunch, and for the most part they care less about the business objectives and more about the elegance of their code. The idea that an engineer would purposefully introduce needless complexity runs counter to my 20 years' experience working with these people. They want their code to be beautiful and their software to be "clean," more than anything. Many developers will actually prioritize this over any business objectives, sometimes to the detriment of the team.
It seems natural that people who do not care at all about the company they work for would mostly care about wasting as little time as possible to keep their job (or at least that seems to be the most common attitude adopted by people)... which could often be achieved by adding some arcane layers in the system that only they understand that have little or no actual usefulness.
Ridiculous. Engineers, and people in general, do not like to work on things that are worthless. In fact, they hate it. Most programmers I know would love to take some time to rip out the code they see as useless-- you often have to practice a great deal of team discipline to stop them.
Are there any works that have ever been developed around the idea of programmers adding artificial complexity ?
Not "artifical" complexity. But here is a Turing-award winning paper on accidental complexity, and here is a bit of writing on incidental versus inherent complexity.
Is artifical complexity commonplace the larger a company or community gets?
I have no doubt that total complexity tends to increase as company size increases. This may be because
The problem domain becomes more complex as more features are added
The problem of technical debt becomes larger as code bases age.
As technology changes over time, and engineers use the latest technology, you end up with a more and more diverse mixture of solutions and approaches, which some might call the Lava Layer anti-pattern.
As software grows, and market share grows, there is more and more risk of changing and refactoring things, so there is less likelihood of these issues being addressed. Product owners won't allow it.
As companies get larger, upper management tries to extract more and more profit out of it, and developers are given less time to work on cleaning up things, which (contrary to your thesis) they will typically beg to do.
As companies get larger, they will tend to employ more outsourced resources, or will acquire companies/buy the rights to software that has already been written rather than grow it in-house. Integrating these various sources together tends to make a bit of a mess.
As companies get larger, it seems like they hire more and more ignorant managers, who may push a prototype that was never meant for release into production, or may attempt to extract unreasonable amounts of work, or will care more about features and marketing than about quality.
It's possible that engineers' attitudes get worse and worse as they feel more and more distanced from their work and have a weaker sense of ownership. That doesn't mean they will add junk just for the hell of it, but it does mean they may not go the extra mile to clean up someone else's mess.
