4 ms·

Enterprise apps are complex because they don't focus on solving the business problem, they focus on the tools and frameworks. Spring is not the cure, it's the

Enterprise apps are complex because they don't focus on solving the business problem, they focus on the tools and frameworks. Spring is not the cure, it's the disease.

sz4kerto 6y ago
This is absolutely not the case. Enterprise app developers (etc.) are not stupid. The domain and the business problem are often extremely complex and hard to understand.
- doctor_eval 6y ago
  My observation from my long career of writing enterprise apps is that frameworks are super complicated with many hidden variables, so when you apply them to a complicated business problem you end up with the square of the complications of both systems. We ended up in framework hell. In response, we ditched all the frameworks we were using, went to pure JavaSE, and ended up with a (much!) faster, more reliable enterprise application that was far, far easier to maintain.
  - foo_barrio 6y ago
    I had this experience with the so-called "app servers" at our company. We also have a daily batch processing system has tons of operational support, db+serivice monitoring, a very useful web UI, logging split out, authorization system etc. It's built around common Nix concepts like files, pids, pipes, etc. Thousands of these batch jobs are little JavaSE programs that launch, do their business, record their progress and report success or failure. Some are python programs and behave the same way. Our JEE apps were deployed to these app servers with very little internal support or expertise that very often had devs having to physically log onto production hosts and figure what in the world was wrong, restarting the app server, grepping logs and in general having to learn about these app servers (and usually just shrugging their shoulders at what went wrong). The sum total of things you had to know to keep the JEE deployments up was as much as you had to know about Nix processes PLUS you still had to know all the Nix stuff, except none of the JEE infra was built out since the app servers were just these monstrous processes with hundreds of db connections and thousands of threads. My team long ago ditched JEE style deployments and have our apps all managed with the batch processing system and have been none of the better for it. Some* of those apps use Spring/Boot but I we've been doing a decent job in the code reviews of just rejecting anything too auto-magikal. Other teams that have stuck with these massive app-servers have stagnated since the deployments are so frail, no one dares make large changes. This is mostly an institutional problem but still the end result was sticking to simpler JavaSE stuff has led to way more productivity.
    - doctor_eval 6y ago
      Yeah your experience absolutely mirrors mine. Don’t even get me started on JPA; I’ve used exactly the same phrasing you did: when you use JPA, now you have to know SQL, JPA and JQL. It makes no sense!
      - lmm 6y ago
        Heh, I found the opposite. JPA is one of the few parts of the ecosystem that actually work and deliver enough value to be worth it.
- tonyedgecombe 6y ago
  Enterprise app developers (etc.) are not stupid. Enterprise developers aren't stupid but enterprise software is some of the worst software I have encountered in my career. When a development team has one captive customer you get the results you would expect.
oblio 6y ago
Enterprise apps are super complex, frequently a lot more complex than startup apps. Someone basically comes with 1 thick tome worth of business knowledge plus 1 thick tome worth of legal restrictions and you're supposed to codify all of that, to the letter, in software. Some of the business logic can make you cry. Software dev: "But that's not clean/elegant". Business owner: "Reality doesn't care about elegant/clean, it cares that we build stuff our customers want and that won't get us sued, so we have to implement it to the T".
- strictfp 6y ago
  I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise. I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platforms", meta-problem solving and needlessly complex deployment environments. Contrast this with my current industry, gaming. Here the problems are real, tangible and hard. Suddenly overcomplication is much less of a problem, because the extra cognitive load becomes too much when your core problem is already hard.
  - foo_barrio 6y ago
    Just as a counterpoint, I've done a little bit of game programming and currently work on a tax reporting system (mostly). Both are full of random shit you have to know for no reason. The game random shit I've had to learn was often tied to very specific platforms at very specific times. The game stuff very often I had to delve into actual math + algos. The tax reporting system I get bogged down and mired in the literal thousands of edge cases and exceptions due to the interactions of all of the laws, sometimes written maliciously by some political entity, or sometimes some local municipality goes against the federal laws leading to literally impossible scenarios. On top of that you have things like your company booking transactions one way that they shouldn't have and is now too much of a pain to change so it has to get reported differently at the reporting layer (which itself is a problem as to why this wasn't noticed initially). Very often the gov't specs themselves are contradictory. Here is an example: stocks can sometimes pay debt interest did you know?! That doesn't come up in any of the fixed income documentation I had to read. But right there in some list of bonds the IRS publishes every year are non-bond things. wtf?! So do you fabricate some new type "debt interest paying thing" of which are mostly composed of bonds and once in a while stocks in your data model? Do you keep your data model clean and fabricate an internal bond to represent the debt part of the stock in these cases and link it to the actual stock? You will have to consult with your legal/tax department and realize if you were to misreport this income what would the resultant fines and loss of customer goodwill is (due to higher chance of them being audited, paying more tax etc)? Do you conclude that your internal team cannot keep up with the ever marching and changing tax law (FATCA anyone wtf?!) and outsource this to a tax reporting company? The scope of our tax reporting is nearly unlimited since the US government seeks to capture all of human endeavor. The results of getting this wrong are very real. People get audited and lose money and sue our company and can go under due to litigation costs. In games, if we fuck up, our company goes under and everyone loses their job but I didn't have to worry so much about potentially ruining the jobs of people outside of our company. This is actual complexity your software will have to deal with no matter your language/platform. In my, admittedly limited (never AAA), experience with games I always seemed to be bumping up against physics (time, memory, latency/speed of light) but with enterprise apps it's almost always bumping up against the sum total of human stupidity past and present.

Enterprise apps are complex because they don't focus on solving the business problem, they focus on the tools and frameworks. Spring is not the cure, it's the disease.

sz4kerto 6y ago

This is absolutely not the case. Enterprise app developers (etc.) are not stupid. The domain and the business problem are often extremely complex and hard to understand.

doctor_eval 6y ago
My observation from my long career of writing enterprise apps is that frameworks are super complicated with many hidden variables, so when you apply them to a complicated business problem you end up with the square of the complications of both systems. We ended up in framework hell. In response, we ditched all the frameworks we were using, went to pure JavaSE, and ended up with a (much!) faster, more reliable enterprise application that was far, far easier to maintain.
- foo_barrio 6y ago
  I had this experience with the so-called "app servers" at our company. We also have a daily batch processing system has tons of operational support, db+serivice monitoring, a very useful web UI, logging split out, authorization system etc. It's built around common Nix concepts like files, pids, pipes, etc. Thousands of these batch jobs are little JavaSE programs that launch, do their business, record their progress and report success or failure. Some are python programs and behave the same way. Our JEE apps were deployed to these app servers with very little internal support or expertise that very often had devs having to physically log onto production hosts and figure what in the world was wrong, restarting the app server, grepping logs and in general having to learn about these app servers (and usually just shrugging their shoulders at what went wrong). The sum total of things you had to know to keep the JEE deployments up was as much as you had to know about Nix processes PLUS you still had to know all the Nix stuff, except none of the JEE infra was built out since the app servers were just these monstrous processes with hundreds of db connections and thousands of threads. My team long ago ditched JEE style deployments and have our apps all managed with the batch processing system and have been none of the better for it. Some* of those apps use Spring/Boot but I we've been doing a decent job in the code reviews of just rejecting anything too auto-magikal. Other teams that have stuck with these massive app-servers have stagnated since the deployments are so frail, no one dares make large changes. This is mostly an institutional problem but still the end result was sticking to simpler JavaSE stuff has led to way more productivity.
  - doctor_eval 6y ago
    Yeah your experience absolutely mirrors mine. Don’t even get me started on JPA; I’ve used exactly the same phrasing you did: when you use JPA, now you have to know SQL, JPA and JQL. It makes no sense!
    - lmm 6y ago
      Heh, I found the opposite. JPA is one of the few parts of the ecosystem that actually work and deliver enough value to be worth it.
tonyedgecombe 6y ago
Enterprise app developers (etc.) are not stupid. Enterprise developers aren't stupid but enterprise software is some of the worst software I have encountered in my career. When a development team has one captive customer you get the results you would expect.

oblio 6y ago

Enterprise apps are super complex, frequently a lot more complex than startup apps. Someone basically comes with 1 thick tome worth of business knowledge plus 1 thick tome worth of legal restrictions and you're supposed to codify all of that, to the letter, in software. Some of the business logic can make you cry. Software dev: "But that's not clean/elegant". Business owner: "Reality doesn't care about elegant/clean, it cares that we build stuff our customers want and that won't get us sued, so we have to implement it to the T".

strictfp 6y ago
I'm sorry, having extensive experience writing enterprise apps I have to refute this. Almost all complexity I've ever seen was rooted in infrastructure, not the inherent complexities of said enterprise. I would even go so far as to say that the enterprise logic was so straight-forward that most programmers spent their time inventing problems, which is how look at the enterprise market. They's a lot of "inner platforms", meta-problem solving and needlessly complex deployment environments. Contrast this with my current industry, gaming. Here the problems are real, tangible and hard. Suddenly overcomplication is much less of a problem, because the extra cognitive load becomes too much when your core problem is already hard.
- foo_barrio 6y ago
  Just as a counterpoint, I've done a little bit of game programming and currently work on a tax reporting system (mostly). Both are full of random shit you have to know for no reason. The game random shit I've had to learn was often tied to very specific platforms at very specific times. The game stuff very often I had to delve into actual math + algos. The tax reporting system I get bogged down and mired in the literal thousands of edge cases and exceptions due to the interactions of all of the laws, sometimes written maliciously by some political entity, or sometimes some local municipality goes against the federal laws leading to literally impossible scenarios. On top of that you have things like your company booking transactions one way that they shouldn't have and is now too much of a pain to change so it has to get reported differently at the reporting layer (which itself is a problem as to why this wasn't noticed initially). Very often the gov't specs themselves are contradictory. Here is an example: stocks can sometimes pay debt interest did you know?! That doesn't come up in any of the fixed income documentation I had to read. But right there in some list of bonds the IRS publishes every year are non-bond things. wtf?! So do you fabricate some new type "debt interest paying thing" of which are mostly composed of bonds and once in a while stocks in your data model? Do you keep your data model clean and fabricate an internal bond to represent the debt part of the stock in these cases and link it to the actual stock? You will have to consult with your legal/tax department and realize if you were to misreport this income what would the resultant fines and loss of customer goodwill is (due to higher chance of them being audited, paying more tax etc)? Do you conclude that your internal team cannot keep up with the ever marching and changing tax law (FATCA anyone wtf?!) and outsource this to a tax reporting company? The scope of our tax reporting is nearly unlimited since the US government seeks to capture all of human endeavor. The results of getting this wrong are very real. People get audited and lose money and sue our company and can go under due to litigation costs. In games, if we fuck up, our company goes under and everyone loses their job but I didn't have to worry so much about potentially ruining the jobs of people outside of our company. This is actual complexity your software will have to deal with no matter your language/platform. In my, admittedly limited (never AAA), experience with games I always seemed to be bumping up against physics (time, memory, latency/speed of light) but with enterprise apps it's almost always bumping up against the sum total of human stupidity past and present.