A couple of years ago I worked for a bank replacing an in-house library that basically moved and transformed data from one database to another with a highly contrieved Spring Batch solution.
There was absolutely nothing wrong with the "ugly" framework code, it was quite beautiful, well structured, configurable and fast.
Somebody didn't like that you didn't write java code and the properties file based DSL was indeed odd, but nothing wrong with it after you bothered to read the library code.
The Spring Batch code was more explicit, but much uglier, overall.
People have to have list items for their yearly review cycle and their CV. "Replaced a legacy system with a more modern solution" can be presented in a light that earns you cookies. But it may be seen as useless by the higher ups if all they care about is new features. You have to know what impresses your boss and your boss' boss or the interviewer at your next job.
> There was absolutely nothing wrong with the "ugly" framework code, it was quite beautiful, well structured, configurable and fast.
I'm sure there is far more to the story than the new guys doing a poor job writig a replacement service.
For example, old code does add maintenance costs just by the fact that it's either tied to old frameworks or even OSes, either of which might not be maintained anymore. Also, I don't feel it's a honest argument to criticize java for the sake of being java. If there was ever a production-minded programming language and tech stack, that would undoubtedly be java.
I'm sure the guys who designed the replacement service would have a few choice words regarding the old service.
There was absolutely nothing wrong with the "ugly" framework code, it was quite beautiful, well structured, configurable and fast. Somebody didn't like that you didn't write java code and the properties file based DSL was indeed odd, but nothing wrong with it after you bothered to read the library code.
The Spring Batch code was more explicit, but much uglier, overall.