|
Smart is reductive, indeed: You're brilliant, I am a genius.
|
|
|
|
|
I wish I could claim that I am a genius. I tested 2 points shy. I blame the out-of-stock Coke machine.
Money makes the world go round ... but documentation moves the money.
|
|
|
|
|
Sander Rossel wrote: Just tell me which button to press, what the desired result is, and I'll dive into that code and have it fixed this afternoon.
Sure:
1. Dive into the button press that is on the front end.
2. Discover that it's being handled by some inane framework, in this case, ExtJS
3. Learn the minimum amount of ExtJS to figure out what controller the click is being routed to.
4. Look at code.
5. Discover it's calling the backend.
6. Recreate the AJAX call and start debugging the backend.
7. Discover after a few hours of wading through layers of ORM and custom SQL that the problem is 5 levels deep in some static update method that is generating custom SQL.
8. Dive into the custom SQL only to discover it has more holes than a worm farm.
9. Sigh.
|
|
|
|
|
But did it take you a year to find?
Also, could someone with plenty of experience with the code could've fixed it easier?
|
|
|
|
|
True... Until you are asked to fix a systemic problem.
I was new, excited, and a quick study. But I noticed a memory leak.
Upon looking into it, they used a reference counting system. But the children often referenced their parent, for access to related data.
They built a memory sieve! Nothing ever got freed up until the program reset. They had some hacks in there to free up entire objects, but they were failing because of the cyclical-references. On top of that, the design was chosen so that "data sets" could be "shared" between graphing and audio objects.
But wait for it... When you added these children to to the audio objects, they got confused as to who was referencing them, because they knew of only their "parent"...
I left it alone. It would have required a complete rewrite. Most users launched the application, measured something, analyzed it, and closed the program down. And if they didn't, the subsequent crashing from running out of memory would force them to! Nobody but me was complaining...
Yes, MOST of the other fixes were easy, as you describe. But they were not architectural in nature!
|
|
|
|
|
But as you said, someone who worked on the application for years or who wrote the whole thing couldn't fix it either
You understood the problem soon enough, didn't take you a year.
You also knew what had to be done to fix it.
But that was so much work no single person could've done it and no team could've done it within the time and budget constraints.
|
|
|
|
|
that's the first thing I give up trying to learn about.
|
|
|
|