• Kev (unregistered)

    Typical, why are people so afraid of reworking awful code?

  • Anonymous (unregistered) in reply to Kev

    More like people are afraid of change.

  • asgjaguausgasd (unregistered) in reply to Kev
    Kev:
    Typical, why are people so afraid of reworking awful code?
    Because the end result is what matters to people that aren't coders; dur.
  • mjm (unregistered) in reply to Kev
    Kev:
    Typical, why are people so afraid of reworking awful code?

    Because it might be reworked by somebody less intelligent than the original developer. Then the entire system is broken. Better to keep the shit that at least runs.

    Think like a manager, not a coder.

  • (cs)

    Rule 2: If it works, break it.

  • (cs)

    Bah, why not just use the best of both worlds? Write a new system that will generate invoices. Then rely on the sort of hack that will keep you up most nights, but not all nights:

    if ($invoice->date < $revisedBySimonDate) { $oldClunkyElseifSystem->Generate($invoice); } else { $newBeautifySystem->Generate($invoice); }

    The system that works and has worked for 10 years stays in place, complete with whatever eccentricities and hacks that keep it alive and working. Any new invoice won't have to rely on the older, discontinued products, and thus can be handled differently.

  • ** SR (unregistered) in reply to Kev
    Kev:
    Typical, why are people so afraid of reworking awful code?

    To a coder it's an abomination. To everyone else it's a working system.

    The fact that it's inelegant is not reason enough to introduce a load of fresh bugs with a rewrite.

  • TheCPUWizard (unregistered)

    If a system meets the needs, then the benefit vs. cost and risk of a re-write is very very very rarely justified.

    Coders wanting to re-implement systems simply because they are not elegant (or are even clinky) is a major problem in software engineering.

    People who watch the TV show "Numbers" should remember an episode a few weeks ago (sometime in October) where major issues (including multiple deaths) resulted directly from engineers NOT taking into account hard realities and always believing they could make things better in a short amount of time.

  • gm (unregistered) in reply to ** SR

    Agreed. The manager was completely correct to refuse the rewrite.

  • EleganceIsPerformance (unregistered) in reply to ** SR

    Except the problem wasn't just that the code was inelegant. It's that the code was running "slower and slower". The performance problems were presumably why the inelegant code was discovered in the first place. In fact, the TRWTF is that when the manager asked "Why would we want to change?", the answer wasn't simply "Uh...because our customers are complaining that even the simplest transaction takes way too long."

  • Bob (unregistered) in reply to halcyon1234

    [quote user="halcyon1234"]if ($invoice->date < $revisedBySimonDate) { $oldClunkyElseifSystem->Generate($invoice); } else { $newBeautifySystem->Generate($invoice); } [quote] I applaud your efforts to ensure that readers of thedailywtf will continue to be entertained for years to follow.

  • Plz Send Me The Code (unregistered)

    It's working and making money? I wouldn't touch it without a whole lot of signing off. And testers. Lots and lots of testers.

  • Steenbergh (unregistered) in reply to Plz Send Me The Code
    Plz Send Me The Code:
    It's working and making money? I wouldn't touch it without a whole lot of signing off. And testers. Lots and lots of testers.

    That's true. However, next to the want of coders to always re-engineer what others made, I think in this case, that it's justified to do so. Performance and maintainability of this code is nigh-zero...

  • Murf (unregistered) in reply to EleganceIsPerformance
    EleganceIsPerformance:
    Except the problem wasn't just that the code was inelegant. It's that the code was running "slower and slower". The performance problems were presumably why the inelegant code was discovered in the first place. In fact, the TRWTF is that when the manager asked "Why would we want to change?", the answer wasn't simply "Uh...because our customers are complaining that even the simplest transaction takes way too long."
    If they asked for the change why would they refuse it?

    Well upgrade the server then. (aka bruteforce) Oh crap That is not a good answer it is working so why change it?

  • eViLegion (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    People who watch the TV show "Numbers" should remember an episode a few weeks ago (sometime in October) where major issues (including multiple deaths) resulted directly from engineers NOT taking into account hard realities and always believing they could make things better in a short amount of time.

    Using the show Numbers in place of a real world example is the real WTF here! ;oP

    (Btw, I actually agree with you - just couldn't resist)

  • Vollhorst (unregistered)

    He could have improved the else-ifs. Simply put the new products and the often shown/bought stuff at the beginning of the decision tree and everything should run faster. ;)

  • Management Victim #654,604,223 (unregistered)

    I WTF'd at the end, when the big bosses back-tracked on their decision to replace the old system with the one Simon was proposing.

    Then I realized what the WTF really was: Simon was what we used to call "hobby jobbing". He wasn't acting on management instructions. He wasn't addressing business or operational concerns. He hadn't taken direction in a meeting where his manager (say, Rob, in honor of this) said "Simon, I'm concerned our shopping cart application is getting a bit slow. See what you can do to speed it up."

    Simon was pursuing a course both self-satisfying and good for the business. But not one that his bosses were aware of and, apparently, would have approved.

    I suspect a lot of code monkeys out here in WTF-land are thinking that the WTF is Simon not being permitted to do the obviously right thing. "Stupid management, too short-sighted to allow me to solve all their website performance problems."

    The real WTF is that solving a problem which isn't an actual problem--not hurting productivity or revenue--and in which the solution imposes new problems (like making Customer Service refer to soft-copies of invoices instead of direct lookups) is generally not a good solution.

    I have to wonder which of Simon's actual tasks he was blowing off to do this journey to the center of the app, the land that code sanity forgot.

    Yes. It's hideous code, and WTF-worthy in the same sense that a bad accident in a road race is compelling. But if it's functioning, you have to lay the organizational ground very carefully to support "fixing" what isn't broke, from the user perspective.

  • Matt (unregistered) in reply to EleganceIsPerformance
    EleganceIsPerformance:
    Except the problem wasn't just that the code was inelegant. It's that the code was running "slower and slower". The performance problems were presumably why the inelegant code was discovered in the first place. In fact, the TRWTF is that when the manager asked "Why would we want to change?", the answer wasn't simply "Uh...because our customers are complaining that even the simplest transaction takes way too long."

    Well said! My sentiments exactly - the problem here seems to be the fact that Simon was just like every other 'coder' (not a developer - doesn't deserve the title). When faced with the (rhetorical) question from his boss he actually cared that it was rhetorical - hence: "However, the more familiar Simon got with the code, the harder it was for him to understand why it was allowed to remain in place for over ten years."

    His boss is clearly a moron: "what we have works already and has been working consistently for the past ten years!" - er... the code is changing all the time and getting slower. Try factoring ongoing maintenance versus refactoring time into the equation.

    CAPTCHA: plaga ... sort of like a spanish beach for drunks?

  • Matt (unregistered) in reply to Management Victim #654,604,223
    Management Victim #654:
    I WTF'd at the end, when the big bosses back-tracked on their decision to replace the old system with the one Simon was proposing.

    Then I realized what the WTF really was: Simon was what we used to call "hobby jobbing". He wasn't acting on management instructions. He wasn't addressing business or operational concerns. He hadn't taken direction in a meeting where his manager (say, Rob, in honor of this) said "Simon, I'm concerned our shopping cart application is getting a bit slow. See what you can do to speed it up."

    Simon was pursuing a course both self-satisfying and good for the business. But not one that his bosses were aware of and, apparently, would have approved.

    I suspect a lot of code monkeys out here in WTF-land are thinking that the WTF is Simon not being permitted to do the obviously right thing. "Stupid management, too short-sighted to allow me to solve all their website performance problems."

    The real WTF is that solving a problem which isn't an actual problem--not hurting productivity or revenue--and in which the solution imposes new problems (like making Customer Service refer to soft-copies of invoices instead of direct lookups) is generally not a good solution.

    I have to wonder which of Simon's actual tasks he was blowing off to do this journey to the center of the app, the land that code sanity forgot.

    Yes. It's hideous code, and WTF-worthy in the same sense that a bad accident in a road race is compelling. But if it's functioning, you have to lay the organizational ground very carefully to support "fixing" what isn't broke, from the user perspective.

    Ohhh interesting take on it - expect at the end it says: "Defeated, Simon went back to his maintenance work and added yet another elseif() block to represent yet another promo offer." so I assumed that this is what led Simon to consider that the whole thing was becoming troublesome (as he opened the file responsible and waited several minutes while his IDE eats up all his resources). And then he did go to managment (we hope he did this before creating a new branch in the companies' VCS of choice and playing about) but he just gave up to easily.

    :)

  • justsomedude (unregistered) in reply to Management Victim #654,604,223
    Management Victim #654:
    I have to wonder which of Simon's actual tasks he was blowing off to do this journey to the center of the app, the land that code sanity forgot.

    This. You will rise to management fast.

  • Dave (unregistered)

    Maybe the boss wasn't being rhetorical. Maybe he actually wanted to know why something should be done before spending developer hours, QA hours on something that requires a change of process for the customer support for the worse? Maybe Simon should be able to come up with a valid reason for this. "It currently takes 15 seconds to bring up and invoice. My estimates indicate that at the current rate we are growing it would take 80 seconds to bring up an invoice by 2012." To which the boss might ask something like "are there any other feasible options with lower risk?" to which the developer could say "well.. we could use a map-kind-of-thing to store the product codes in.. that would make large orders run almost as fast as single-item orders. I'm guessing that would work."

  • Migala (unregistered) in reply to Management Victim #654,604,223
    Management Victim #654:
    Then I realized what the WTF really was: Simon was what we used to call "hobby jobbing". He wasn't acting on management instructions. He wasn't addressing business or operational concerns.

    Simon may not have been acting on management instructions, but he was addressing business concerns: It is (too) complicated to add new products or change existing ones, and the system is unresponsive. Taking action against this, whether instructed to or not, is A Good Thing.

    TheRealWTF is that he gave up so quickly when his boss asked him why this was needed (rhetorically or not). Instead of assuming his boss is a moron, and having all the facts had already made a (wrong) decision, he should have said:

    • it now takes a lot of effort to update the product catalog
    • if we change this, it will be so simple even the business users can do it themselves
    • both saving time and increasing flexibility
    • for a minimal investment in time (x hours), and with minimal risks (such and so)...
    • so what should i do?

    Fair chance his manager would have been happy with his initiative and told him to go ahead and change it.

  • (cs) in reply to Management Victim #654,604,223
    Management Victim #654:
    The real WTF is that solving a problem which isn't an actual problem--not hurting productivity or revenue

    While I don't disagree with the conclusion that it was right for management to reject the proposed change, I'd question whether it can be safely assumed that a core business function which is getting slower and slower at a linear rate is not hurting productivity or revenue.

  • (cs) in reply to Matt
    You see, the important thing about invoices is that they must be immutable.
    ...the code is changing all the time...
    ...the company's VCS of choice...
    Words fail me.
  • (cs) in reply to Vollhorst
    Vollhorst:
    He could have improved the else-ifs. Simply put the new products and the often shown/bought stuff at the beginning of the decision tree and everything should run faster. ;)

    Assuming the order of the if ... else-if blocks can be changed that is, the time taken to shuffle around 16000 lines of such blocks and then test they are working is potentially a monstrous time sink.

    You then also get the problem of where to locate existing blocks - they start new -> old then go old -> ancient and finally ancient -> old again, this is a minefield for whoever has to maintain this new 'improved' version.

  • Anonymously Yours (unregistered)
    TheCPUWizard:
    If a system meets the needs, then the benefit vs. cost and risk of a re-write is very very very rarely justified.
    This is a very naive act of hyperbole.

    I find myself in a similar position to Simon now, except its with a denormalized database. The most central table of the site has grown in size because of quick fixes and easy additions done because we're never allowed time to refactor. The result is that the site is able to handle less and less traffic, and if this goes on will eventually be unable to handle enough volume necessary to make a profit. This has been made clear to management, repeatedly, and the response is always that the site isn't crashing so we can't stop the business to let Tech do it. They also don't think they should have to pay for additional hardware unless the site is actively crashing.

    So, no, if the system meets the needs that means nothing in regards to if refactoring is justified. If the needs change then the system must be capable of meeting the needs that haven't happened yet.

  • Anonymous (unregistered)

    What I understand from reading this story is that it wasn't Simon's job to refactor or rewrite the spaghetti code - his job was simply to add a new item to it. So on the one hand I would say well done for looking into ways of improving the long-term maintainability of the code; but on the other hand, he should not have been wasting time on work that was never tasked to him in the first place. If he wasn't actually told to do the work then he shouldn't really be surprised when his boss tells him to get on with something else.

  • (cs) in reply to Anonymously Yours
    Anonymously Yours:
    TheCPUWizard:
    If a system meets the needs, then the benefit vs. cost and risk of a re-write is very very very rarely justified.
    This is a very naive act of hyperbole.

    I find myself in a similar position to Simon now, except its with a denormalized database. The most central table of the site has grown in size because of quick fixes and easy additions done because we're never allowed time to refactor. The result is that the site is able to handle less and less traffic, and if this goes on will eventually be unable to handle enough volume necessary to make a profit. This has been made clear to management, repeatedly, and the response is always that the site isn't crashing so we can't stop the business to let Tech do it. They also don't think they should have to pay for additional hardware unless the site is actively crashing.

    So, no, if the system meets the needs that means nothing in regards to if refactoring is justified. If the needs change then the system must be capable of meeting the needs that haven't happened yet.

    Personally I would consider future growth as part of 'the needs' if the system is functioning now but is going to fail in the far future then it meets the required needs. If it is functioning now and due to fail in a sooner time frame then I would consider it not meeting the needs.

    If the time taken to refactor can be provided without disrupting the service then it is (should be) an easy decision, however management (for whatever reason) often let problems exist past the point were fixes are practical and the problem turns into one of keeping the existing system up as no other solution appears possible.

    If the system is going to fail then there is a massive financial impact looming and this is the point that should be brought to the appropriate persons attention, preferable with hard figures to back up the prediction.

    If the management still refuse to act then make sure all your documentation and paperwork backs you up, keep your CV up to date and by keeping your eye on the current system you will know when to start looking for the next job...

  • (cs) in reply to EleganceIsPerformance
    EleganceIsPerformance:
    Except the problem wasn't just that the code was inelegant. It's that the code was running "slower and slower". The performance problems were presumably why the inelegant code was discovered in the first place. In fact, the TRWTF is that when the manager asked "Why would we want to change?", the answer wasn't simply "Uh...because our customers are complaining that even the simplest transaction takes way too long."
    No kidding, what a pussy. He didn't even have the balls to present a valid reason for the change?
  • Jim (unregistered) in reply to halcyon1234
    halcyon1234:
    Bah, why not just use the best of both worlds? Write a new system that will generate invoices. Then rely on the sort of hack that will keep you up most nights, but not all nights:

    if ($invoice->date < $revisedBySimonDate) { $oldClunkyElseifSystem->Generate($invoice); } else { $newBeautifySystem->Generate($invoice); }

    Fantastic - replace 16000 lines of if / else with 16001. Genius.

  • mattymattmatt (unregistered) in reply to Management Victim #654,604,223
    Management Victim #654:

    The real WTF is that solving a problem which isn't an actual problem--not hurting productivity or revenue--and in which the solution imposes new problems (like making Customer Service refer to soft-copies of invoices instead of direct lookups) is generally not a good solution.

    Umm... so old fashioned receipts aren't a good solution anymore? Granted unless the pdf's were setup in a way that was easily searchable that wouldn't be a good solution at all. But having to execute 16,000 lines of code or just search a couple of pdf's for a particular receipt sounds like a pretty big difference in speed and efficiency.

  • Anonymously Yours (unregistered) in reply to spenk
    spenk:
    Anonymously Yours:
    TheCPUWizard:
    If a system meets the needs, then the benefit vs. cost and risk of a re-write is very very very rarely justified.
    This is a very naive act of hyperbole.

    I find myself in a similar position to Simon now, except its with a denormalized database. The most central table of the site has grown in size because of quick fixes and easy additions done because we're never allowed time to refactor. The result is that the site is able to handle less and less traffic, and if this goes on will eventually be unable to handle enough volume necessary to make a profit. This has been made clear to management, repeatedly, and the response is always that the site isn't crashing so we can't stop the business to let Tech do it. They also don't think they should have to pay for additional hardware unless the site is actively crashing.

    So, no, if the system meets the needs that means nothing in regards to if refactoring is justified. If the needs change then the system must be capable of meeting the needs that haven't happened yet.

    Personally I would consider future growth as part of 'the needs' if the system is functioning now but is going to fail in the far future then it meets the required needs. If it is functioning now and due to fail in a sooner time frame then I would consider it not meeting the needs.
    That was the point I was making to the person I was responding to. You're basically repeating what I said back to me as if it addressed something that was still outstanding.

    spenk:
    If the system is going to fail then there is a massive financial impact looming and this is the point that should be brought to the appropriate persons attention, preferable with hard figures to back up the prediction.
    Yes, and if you'd read my comment instead of skimming it you'd know that this had already been done repeatedly.
  • mattymattmatt (unregistered) in reply to justsomedude
    justsomedude:
    Management Victim #654:
    I have to wonder which of Simon's actual tasks he was blowing off to do this journey to the center of the app, the land that code sanity forgot.

    This. You will rise to management fast.

    Hahaha agreed. If everyone thinks like this why the hell would companies have maintainers to begin with. "if it works who gives a crap if its slow and written poorly"....yeah.....

  • Dazed (unregistered) in reply to TheCPUWizard
    TheCPUWizard:
    If a system meets the needs, then the benefit vs. cost and risk of a re-write is very very very rarely justified.
    Because of course being able to react quickly to changed needs in the future is almost never a business requirement.
  • Benjamin (unregistered)

    Yes, Yes!, YES!! Management hires developers to NOT tell them when the infrastructure is beginning to crumble so as NOT to avoid future disaster.

    It's exactly the same as engineers and bridges, only instead of people dying the company loses profit and customer base.

    The real culprit here is the writers on Star Trek, for convincing every manager out there that they are Captain Kirk and the engines will not explode when pushed 20% beyond maximum capacity simply because the Captain ordered it to be so.

    If the Captain says that the energon crystals can be refitted in 30 seconds when the manual states it takes space dock and 6 months of work, then obviously the Captain is correct! Make it so!!

    Why allow reality to intrude on good television? Or on management's decisions for that matter?

  • Procrastinator (unregistered) in reply to Management Victim #654,604,223

    As a professional, your job is not merely to write code, but to also warn management of possible future problems and risks to business you may become aware of. Granted, the system works now, but what would happen when the system finally becomes too large to rewrite, and too slow to work? I can hear management now, "Simon, how long have you known about this? And why didn't you say something sooner?" The real WTF is that Simon couldn't muster the courage to say something like, "Yes, I know it works now, but it will become progressively slower unless rewritten, and it will cost you less to do it sooner rather than later." In any case, Simon is now cleared of any liability for the inevitable system crash and lost business that such a system will eventually produce.

  • (cs) in reply to Procrastinator
    Procrastinator:
    In any case, Simon is now cleared of any liability for the inevitable system crash and lost business that such a system will eventually produce.
    But can't you just hear them now?

    "You didn't tell us it would be this bad!"

    /facepalm

  • AnimalFarmPig (unregistered)

    The easy medium-term solution here is to just throw hardware at the problem. Moving to faster machines from time to time is probably more reasonable than rebuilding the whole system.

  • Bart (unregistered)

    Eventually there will be enough screaming by the users that it will get done. You may get fired for not being able to maintain it when that happens but, keep your chin up, the next guy will be allowed to actually fix it.

  • Matt (unregistered) in reply to EleganceIsPerformance

    You could get a massive performance increase without breaking anything simply by replacing the massive if tree with a select / switch block.

  • (cs) in reply to Matt
    You could get a massive performance increase without breaking anything simply by replacing the massive if tree with a select / switch block.

    I posted this comment before registering. Just taking credit...

  • iToad (unregistered)

    This looks like a classic case of Code Cancer. The code started out with only a few elseifs, or other bad practices. However, bad practices tend to grow uncontrollably, until physical symptoms began to appear. Once this happens, there are no good options. You are forced to choose between the software development equivalents of chemotherapy or radical surgery.

    Like other forms of cancer, early detection and treatment is the best option.

  • Bim Job (unregistered)

    Kids these days are wimps.

    (1) Hash. Or hash-map. (2) Do not show it to your manager. Keep it on the side. (3) Wait for somebody (customer support, etc -- somebody who actually gets hurt by this) to walk by your desk/cuboid. (4) Ask an innocent question. "That's about five seconds per query, isn't it?" (5) Wait for answer. These people have been brainwashed. "Of course ... well, about that, anyway." (6) Demonstrate parallel system with Magic Hash (Non-Smokeable). (7) "Well, that certainly seems to ... er ... work." (8) Ask customer service person to recommend new (magic! instant! not-quite-checked-in-to-madness) solution to customer service management.

    Works every time.

    Otherwise: find a less awful job.

  • forgottenlord (unregistered)

    Not to refute the claim that this is a full-on WTF, but two thoughts:

    1. I would suspect that the else if's would generally grow linearly (with exception to the fact that the company is growing, but still) while processing power is still aiming for exponential growth so would throwing equipment at this at least keep them ahead of the wave of slowdown?
    2. If, instead of continually adding the new deals to the end of the else if list you added them to the front, would you still experience the same decrease in performance? After all, special deals from 10 years ago would only be looked up when you have extraordinary circumstances (how often does a customer complain about a 10 year old receipt), but the products that just came out yesterday are going to be hot button items.

    No, neither of these fix the fundamental WTF, but (especially #2) strike me as hack fixes that somewhat justify the business decision

  • Jonathan Collins (unregistered)

    I think I missed the part where he solved the elseif hell?

    Or was he planning to spend his time coding elseifs, printing out the related invoices, then removing the elseifs when the promos were finished?

  • A Gould (unregistered) in reply to Anonymous
    Anonymous:
    More like people are afraid of change.

    And for good reason. You're asking them to switch from a bad-but-functioning (at least for the moment) system to an unknown. Maybe the new system will be better. Maybe it's the best thing since cat-6 cable.

    Or maybe it'll be the next entry on this site.

    Local example: we just changed systems here from

    • a system that's a bit arcane, definately bare-bones, but it works to
    • a system that barely meets the original functionality, has a tendency to crash, and the promised new features either don't work or have showstopping bugs. Oh, and it managed to become more arcane in the process.

    My suggestion to the guy would be to start building the new system now - when the old one comes, he's already ahead of the plot to build a new one (which makes you look smart). If that day never comes, you at least got to work on an interesting problem.

    That's my personal strategy around here.

    1. Identify problem coming up, but that management isn't caring about yet.
    2. Start working on solution in work-spare time. (While waiting for return phone calls, in meetings, etc.)
    3. When it hits the fan and they come running for a fix, tell them you'll start working on it. Give them a time estimate based on starting from zero. (And for the love of $DIETY, don't tell them you've got a fix already!)
    4. Get fix done in record time due to your head start.
    5. Look like hero.
    6. ??? <-- still figuring this part out
    7. Profit!

    And if it never hits the fan, I'm at least building my skills.

  • DilithiumCrystalMeth (unregistered) in reply to Benjamin
    Benjamin:
    Yes, Yes!, YES!! Management hires developers to NOT tell them when the infrastructure is beginning to crumble so as NOT to avoid future disaster.

    It's exactly the same as engineers and bridges, only instead of people dying the company loses profit and customer base.

    The real culprit here is the writers on Star Trek, for convincing every manager out there that they are Captain Kirk and the engines will not explode when pushed 20% beyond maximum capacity simply because the Captain ordered it to be so.

    If the Captain says that the energon crystals can be refitted in 30 seconds when the manual states it takes space dock and 6 months of work, then obviously the Captain is correct! Make it so!!

    Why allow reality to intrude on good television? Or on management's decisions for that matter?

    <nerd> Ignoring for the moment that there are no energon crystals in Star Trek and that it was Captain Picard who said "Make it so", not Captain Kirk, the real lesson you should have taken from Star Trek is that Scotty probably wrote the manual saying that it would take six months when he knew all along that it would only take 20 seconds. </nerd>
  • Michael (unregistered) in reply to forgottenlord
    forgottenlord:
    Not to refute the claim that this is a full-on WTF, but two thoughts: 1) I would suspect that the else if's would generally grow linearly (with exception to the fact that the company is growing, but still) while processing power is still aiming for exponential growth so would throwing equipment at this at least keep them ahead of the wave of slowdown? 2) If, instead of continually adding the new deals to the end of the else if list you added them to the front, would you still experience the same decrease in performance? After all, special deals from 10 years ago would only be looked up when you have extraordinary circumstances (how often does a customer complain about a 10 year old receipt), but the products that just came out yesterday are going to be hot button items.

    No, neither of these fix the fundamental WTF, but (especially #2) strike me as hack fixes that somewhat justify the business decision

    except, (assuming that the code posted in TFA is representative of the system) some scripting language is being used (looks like PHP to me) and that's 16,000 lines that have to be read from disk, lexed, parsed, syntax verified, and ... then finally... executed for each invocation of the page.

    even if you assume byte-code pre-optimization and caching (ala the Zend engine) which I doubt was in use in a 10+ year old project, you're still talking about an expensive proposition...

  • Bim Job (unregistered) in reply to Michael
    Michael:
    except, (assuming that the code posted in TFA is representative of the system) some scripting language is being used (looks like PHP to me) and that's 16,000 lines that have to be read from disk, lexed, parsed, syntax verified, and ... then finally... executed for each invocation of the page.

    even if you assume byte-code pre-optimization and caching (ala the Zend engine) which I doubt was in use in a 10+ year old project, you're still talking about an expensive proposition...

    What, you're saying that the vast preponderance of PHP programmers have no clue what they're doing?

    Perish the thought.

  • Michael (unregistered) in reply to Michael
    Michael:
    forgottenlord:
    Not to refute the claim that this is a full-on WTF, but two thoughts: 1) I would suspect that the else if's would generally grow linearly (with exception to the fact that the company is growing, but still) while processing power is still aiming for exponential growth so would throwing equipment at this at least keep them ahead of the wave of slowdown? 2) If, instead of continually adding the new deals to the end of the else if list you added them to the front, would you still experience the same decrease in performance? After all, special deals from 10 years ago would only be looked up when you have extraordinary circumstances (how often does a customer complain about a 10 year old receipt), but the products that just came out yesterday are going to be hot button items.

    No, neither of these fix the fundamental WTF, but (especially #2) strike me as hack fixes that somewhat justify the business decision

    except, (assuming that the code posted in TFA is representative of the system) some scripting language is being used (looks like PHP to me) and that's 16,000 lines that have to be read from disk, lexed, parsed, syntax verified, and ... then finally... executed for each invocation of the page.

    even if you assume byte-code pre-optimization and caching (ala the Zend engine) which I doubt was in use in a 10+ year old project, you're still talking about an expensive proposition...

    sorry, my point being that the execution in some scripting languages can be one of the shortest phases of the execution of the page (obviously there are exceptions for DB and network accesses), and that even with the conditionals put into a "more optimized" order, if the execution is already faster than fetching from disk and other phases, it's not going to have much of an impact.

Leave a comment on “Immutable Invoices”

Log In or post as a guest

Replying to comment #291415:

Log Out

« Return to Article