My job is exactly to fix code which was not understood by its creators. And this “I have no idea why, but it works” (until it doesn’t) is the main cause of most of the problems which I work on.
For example, at my current company the developer who introduced a “clever” navigation system didn’t know how HTML forms should be used, and why servers still allowed what they did. It worked. Now, 20+ years later that sole developer’s stupid decision, and lack of HTML best practices will cost my company a few million dollars (and by the way already cost probably a few million). A missing day of learning (and by the way a clear sign, that that developer should’ve never trusted with this task).
Senior developers learn this, and I’ve never seen that better developers would be satisfied and would say “yeah, I fixed it”, when they don’t understand the what and how completely, even when it’s not strictly necessary. They burned themselves enough times.
You've got me curious, how did the developer's misunderstanding of forms cost millions? Was it submitting duplicate orders? Blocking submission of valid orders causing lost business?
I think it's an error to bring that up here though, where we're talking about someone patching a closed source app for their personal use. Is it worth the cost/benefit of decompiling and studying the app's code sufficiently long to be highly confident of the fix?
Sloppiness and "good enough" has its place. So does full effort correctness.
Maybe you’re right. I hardly disagree, but those are just opinions.
The main culprit is that the backend is Java EE, and they used a single form for multiple things. This is a 20+ years old software, so they had to used request parameters and attributes everywhere. It’s impossible to locate where a given parameter is used or where attributes are created and used exactly. That’s the first problem. Second, is this single form per page thing. They use that HTML form for everything. Even page navigation, they just discard unnecessary fields on server side. This means that they change that form from JavaScript all the time. Sometime the generated action is not used at all, it’s overwritten with every event. And a single input can be used for multiple things. Third, they used a very flexible framework, which was outdated 10 years ago, so it definitely needs to be replaced.
Add these together, you have terrible spaghetti code for 350+ pages with 1000+ endpoints. There is no separation of code even on HTML level. I know where this “use only one form” came from. I found the ancient doc of that framework, where it mentioned. The problem is that they meant a form object on server side per page (and not per endpoints), and not on client side. And they fucked up completely, because they started to use multiple form objects per page, and single client side HTML forms.
So now, replacing that old framework starts with a hefty refactoring, creating individual HTML forms for example. It will take at least half a year for a team, just the refactoring, because it’s very difficult to split those forms, since request attributes and parameters used everywhere.
For example, at my current company the developer who introduced a “clever” navigation system didn’t know how HTML forms should be used, and why servers still allowed what they did. It worked. Now, 20+ years later that sole developer’s stupid decision, and lack of HTML best practices will cost my company a few million dollars (and by the way already cost probably a few million). A missing day of learning (and by the way a clear sign, that that developer should’ve never trusted with this task).
Senior developers learn this, and I’ve never seen that better developers would be satisfied and would say “yeah, I fixed it”, when they don’t understand the what and how completely, even when it’s not strictly necessary. They burned themselves enough times.