4

Isn’t it delightful when you come in to a large project to discover that they have a large underlying core that no one wants to touch but everyone relies on.

Quickly perusing the code you realize that the base was clearly created by someone who found their first tutorials for Java, but were previously a c developer.

It’s funny cause this code is of course from ~20 years ago and in different sections you can tell they were a C developer, a business admin, a Db admin, a junior conforming to pressures from others.

I recently looked at the deep rooted abuses of Java beans, and this entire internally created state management engine that serves no purpose but to create contrived complexity.

The use of propriety tools, that they paid lots for that perform incredibly simple tasks that have long since been solved by the open source community. Many of which are long defunct.

And the constant focus is on monkey patching the engine to solve small issues, which bloat the time to deal with issues. Since everything needs to be tested by their methodologies.

The inability to understand that the underlying structure is the issue and that tackling that, rather than just shifting the entire solution to new languages will suddenly solve the problems(or other underlying systems).

It’s just sad.

Comments
  • 1
    Don't forget about the part where you're assigned to a internal tool that is held together by hot glue and scotch tape, and then you must support it because the previous developer dipped the fuck out because that whole section of the company is fucking cancer
Add Comment