> Complex enterprise apps are often complex because the use case and the environment is complex.
Uh maybe... the real question is where does that complexity come from. Is it intrinsic to the problem or just bureaucratic slob? Given a framework so popular, what are the incentives to go uphill and challenge assumptions - with the likely risk of being fired - or just concede and ad your little contrived contribution to the problem?
From my experience, enterprise apps are generally complex because they are a combination of:
- environment: integration of a large amount of services - and a good amount of them are legacy and idiosyncratic
- use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all. This is IMO the main difference between a "pure" greenfield startup kind of project and the enterprise one.
- add another layer of burocracy and complex environment to navigate
And with that you got the enterprise app world :).
In the end whatever framework is chosen, the most important property is the availability of common language/patterns.
> use case: enterprise app are at the intersection of real life and the virtual world: the rules are messy, illogical and have a baggage of 20/30+ years. Thus they cannot be changed at all.
This is in my experience exactly the problem. They can be changed and should be changed as it would save everyone boatloads of time and money. Engineers need to advocate these business process simplifications, and managers need to illustrate the ROI of making such simplifications.
One has to challenge nonsensical requirements: it’s a critical part of engineering.
Enterprise as in "sold to enterprises" or as in "created by enterprises"?
Both are complex, but for different reasons.
Software that is sold to enterprises is complex because they compete on number of features (in checklists), and there is no pressure for quality since the software users have little saying on what software gets brought.
Software that is created by enterprises for internal use is complex because the enterprises themselves are complex. They are full of rules, created by different people with very different goals, that add up with time, and the applications must deal with them.
> Software that is created by enterprises for internal use is complex because the enterprises themselves are complex. They are full of rules, created by different people with very different goals, that add up with time, and the applications must deal with them.
Maybe it's just me and my scarce disposition for forgiveness, but after several years I tend to believe complexity emerges as a consequence of superficial understanding, diffuse aversion to analysis and outright pool analytical skills.
agree on poor analytical skills.
top talent devs tend to work on front-office apps that generate $, and not the backoffice intranet type apps for internal employees and processes.
i think it is a function of compension difference as well and dev self-selection
Uh maybe... the real question is where does that complexity come from. Is it intrinsic to the problem or just bureaucratic slob? Given a framework so popular, what are the incentives to go uphill and challenge assumptions - with the likely risk of being fired - or just concede and ad your little contrived contribution to the problem?