This is from hearsay, since I was only there a few weeks before getting out, so I only spent some time on the floor and looked at the code for a bit:
It was a municipal management system that grew over time (decades).
At some stage a government standards body raised the legacy risk inherent in the Natural Adabas codebase.
Some (pretty impressive) 3rd party tool was used to transpile the codebase to a more "modern Java web application architecture".
The code wasn't idiomatic Java and used some extension libraries to supply missing capabilities. For example I don't recall ever seeing any other Java system that uses continuations.
I spent an entire day tracing one field from the front-end to the database. I documented the components, flows, logic and db structures and then asked one of the team leads to verify if I got it right. She confirmed that I did. I then asked what the code on question actually does, functionally.
She replied something to the effect of "Good heavens, I don't know either - you'll need to speak to one of the functional guys and then spend some time with the Natural code from before the transpilation".
She needed about 6 months to get a new Java dev to a level where they could do minor feature requests or bug fixes. Understandably her ability to retain developers was quite low - they tended to leave quickly after spending time with the system.
Business didn't seem to get why the velocity for new features was so slow.
They didn't have an architect, documentation was fragmentary.
Previous modernisation initiatives had already become obsolete as well: IIRC the App server was Glassfish and front-end (web) components were using some JBoss widget library that was already deprecated at the time.
It was a municipal management system that grew over time (decades).
At some stage a government standards body raised the legacy risk inherent in the Natural Adabas codebase.
Some (pretty impressive) 3rd party tool was used to transpile the codebase to a more "modern Java web application architecture".
The code wasn't idiomatic Java and used some extension libraries to supply missing capabilities. For example I don't recall ever seeing any other Java system that uses continuations.
I spent an entire day tracing one field from the front-end to the database. I documented the components, flows, logic and db structures and then asked one of the team leads to verify if I got it right. She confirmed that I did. I then asked what the code on question actually does, functionally.
She replied something to the effect of "Good heavens, I don't know either - you'll need to speak to one of the functional guys and then spend some time with the Natural code from before the transpilation".
She needed about 6 months to get a new Java dev to a level where they could do minor feature requests or bug fixes. Understandably her ability to retain developers was quite low - they tended to leave quickly after spending time with the system.
Business didn't seem to get why the velocity for new features was so slow.
They didn't have an architect, documentation was fragmentary.
Previous modernisation initiatives had already become obsolete as well: IIRC the App server was Glassfish and front-end (web) components were using some JBoss widget library that was already deprecated at the time.
Like I said, I left quickly.