7 ms·

There's a very good reason why Spring is used so widely. Complex enterprise apps are often complex because the use case and the environment is complex. E.g.:

There's a very good reason why Spring is used so widely. Complex enterprise apps are often complex because the use case and the environment is complex. E.g.: - integration testing and unit testing is required - transparently pluggable backends for message queues so that locally you can use SQLite as your pub/sub storage but in production it's Google P/S - standardized health check endpoints for all your apps ... The list is infinite. You can make a decision for each point or you can agree with the team that you're using whatever Spring provides. In a team with 100 devs, simplifying and unifying decisions is extremely important. And Spring _works_. I don't like it either, but it works. The alternative is: solving all the problem that Spring solves with different tooling. And no, you can't avoid dependency injection in a 700 kLOC medical application, because you need to test the hell out of it.

lmm 6y ago
Spring proper is (relatively) fine; you can make applications with it that are more-or-less maintainable. Spring Boot is very different. It's a write-only framework, and while businesses may have enthusiastically adopted it, it's new enough that they haven't (yet) had to pay the maintenance costs and realise how bad they are.
- simmerup 6y ago
  What do you mean by write-only framework?
  - nwatson 6y ago
    WOF == you understand your software while you're writing/developing it but give it a rest for a Trump's "two weeks" and you'll have no clue what you did.
    - Pet_Ant 6y ago
      Apparently Donald Trump always said "two weeks". I was unaware of this meme. * https://www.axios.com/trumps-timeline-always-two-weeks-1513302785-b6370a4f-bb5e-434a-80ca-1249c7cf2baa.html https://www.axios.com/trumps-timeline-always-two-weeks-15133... * https://www.bloomberg.com/news/articles/2017-06-06/in-trump-s-white-house-everything-s-coming-in-two-weeks https://www.bloomberg.com/news/articles/2017-06-06/in-trump-...
  - evilduck 6y ago
    Write-only in this context means that the cost of maintaining something vastly exceeds the cost of rewriting that something from scratch. I don't know Spring and Spring Boot well enough to pass judgement, but this situation generally arises in software when you have a language or framework that's reasonably expressive, where the language has a lot of sigils or keywords and it has "shortcuts" that you have to grok before you can really understand codebases that use those shortcuts (like annotations or heavy/excessive use of design patterns). It leads to software solutions that are only well understood by the original authors due to their specific knowledge and problem solving approach and anyone who comes along later must have the exact same overlap of knowledge and skills otherwise they'll find it easier to start fresh. This includes the original authors if the time lapse has been long enough. This often then leads to the next phase of miserable software jobs, the second-system effect.
- krooj 6y ago
  I agree with this, having recently gone through the exercise of creating some "onboarding" apps for new grads using Spring 5 and XML, then again with annotations. All the underpinnings for a non-Boot application are still there and mainly sane. Spring Boot absolutely yields write-once throw away, and you _must_ consider the source: Pivotal is a contracting shop, so it's in their interests to hook people into an ecosystem that they happen to be experts in. I'm surprised this fact is lost on most.
eecc 6y ago
> 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?
- syjer 6y ago
  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.
  - tatersolid 6y ago
    > 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.
- marcosdumay 6y ago
  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.
stevoski 6y ago
> In a team with 100 devs, simplifying and unifying decisions is extremely important. I agree with this. Unfortunately, Spring is often chosen for projects with much smaller teams too. Just 1 to 5 devs on what is fundamentally just a CRUD app. Wrong tool for the job.
- oweiler 6y ago
  I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.
  - eecc 6y ago
    That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by yourself (discovering all the undocumented gotcha’s along the way.)
    - soco 6y ago
      Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.
      - eecc 6y ago
        Well, as someone else on this thread wrote, it does happen all the times you're not preparing for a presentation or a blog. If you're building something marginally different from the routine the curtain is drawn, and IMHO you're probably better off buying a shrink-wrapped ready-made SAAS.
      - 6y ago
strictfp 6y ago
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.
selfhoster11 6y ago
The "different tooling" you mention should be the Java language itself. Let's not kid ourselves, literally no one writes enterprise applications in Java without some kind of a framework, and lives to tell the tale/doesn't go crazy. Since Spring is a de-facto "official" framework to write Java apps in, we might as well clean it up for inclusion into the core Java language, with attention paid to transparency to tooling in IDEs.
cutler 6y ago
I don't know about that. Dmitri Sotnikov, joint author of "Web Development With Clojure", worked on a similar app and didn't even need types or OOP let alone a monster like Spring.
deleted 6y ago
[deleted]

lmm 6y ago

Spring proper is (relatively) fine; you can make applications with it that are more-or-less maintainable. Spring Boot is very different. It's a write-only framework, and while businesses may have enthusiastically adopted it, it's new enough that they haven't (yet) had to pay the maintenance costs and realise how bad they are.

simmerup 6y ago
What do you mean by write-only framework?
- nwatson 6y ago
  WOF == you understand your software while you're writing/developing it but give it a rest for a Trump's "two weeks" and you'll have no clue what you did.
  - Pet_Ant 6y ago
    Apparently Donald Trump always said "two weeks". I was unaware of this meme. * https://www.axios.com/trumps-timeline-always-two-weeks-1513302785-b6370a4f-bb5e-434a-80ca-1249c7cf2baa.html https://www.axios.com/trumps-timeline-always-two-weeks-15133... * https://www.bloomberg.com/news/articles/2017-06-06/in-trump-s-white-house-everything-s-coming-in-two-weeks https://www.bloomberg.com/news/articles/2017-06-06/in-trump-...
- evilduck 6y ago
  Write-only in this context means that the cost of maintaining something vastly exceeds the cost of rewriting that something from scratch. I don't know Spring and Spring Boot well enough to pass judgement, but this situation generally arises in software when you have a language or framework that's reasonably expressive, where the language has a lot of sigils or keywords and it has "shortcuts" that you have to grok before you can really understand codebases that use those shortcuts (like annotations or heavy/excessive use of design patterns). It leads to software solutions that are only well understood by the original authors due to their specific knowledge and problem solving approach and anyone who comes along later must have the exact same overlap of knowledge and skills otherwise they'll find it easier to start fresh. This includes the original authors if the time lapse has been long enough. This often then leads to the next phase of miserable software jobs, the second-system effect.
krooj 6y ago
I agree with this, having recently gone through the exercise of creating some "onboarding" apps for new grads using Spring 5 and XML, then again with annotations. All the underpinnings for a non-Boot application are still there and mainly sane. Spring Boot absolutely yields write-once throw away, and you _must_ consider the source: Pivotal is a contracting shop, so it's in their interests to hook people into an ecosystem that they happen to be experts in. I'm surprised this fact is lost on most.

eecc 6y ago

> 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?

syjer 6y ago
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.
- tatersolid 6y ago
  > 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.
marcosdumay 6y ago
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.

stevoski 6y ago

> In a team with 100 devs, simplifying and unifying decisions is extremely important. I agree with this. Unfortunately, Spring is often chosen for projects with much smaller teams too. Just 1 to 5 devs on what is fundamentally just a CRUD app. Wrong tool for the job.

oweiler 6y ago
I disagree. I can spin up a CRUD service with Spring Boot in an hour including validation, health checks, db migrations, API documentation and what not. It lets me move fast while taking care of the boring stuff. Nothing to do with team size.
- eecc 6y ago
  That’s all fine and nice, except when the magik doesn’t work and you’re ctrl-clicking for hours trying to figure out what darn annotation is breaking the whole incantation. Or you realize a that the tiny tiny small configuration change you need isn’t contemplated by the code supporting the auto-magik, so you start adding overrides which turn off the autoconf, and you have to manually configure the whole beast by yourself (discovering all the undocumented gotcha’s along the way.)
  - soco 6y ago
    Luckily this doesn't happen all that often. Unfortunately this is gonna happen in every framework. Compromises is what you always get when reusing somebody else's framework/program/anything basically, because use cases are never 100% similar.
    - eecc 6y ago
      Well, as someone else on this thread wrote, it does happen all the times you're not preparing for a presentation or a blog. If you're building something marginally different from the routine the curtain is drawn, and IMHO you're probably better off buying a shrink-wrapped ready-made SAAS.
    - 6y ago

strictfp 6y ago

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.

selfhoster11 6y ago

The "different tooling" you mention should be the Java language itself. Let's not kid ourselves, literally no one writes enterprise applications in Java without some kind of a framework, and lives to tell the tale/doesn't go crazy. Since Spring is a de-facto "official" framework to write Java apps in, we might as well clean it up for inclusion into the core Java language, with attention paid to transparency to tooling in IDEs.

cutler 6y ago

I don't know about that. Dmitri Sotnikov, joint author of "Web Development With Clojure", worked on a similar app and didn't even need types or OOP let alone a monster like Spring.

deleted 6y ago

[deleted]