• Company names need to be used.... (unregistered)

    The correct answer...

    And simon freshened his resume and started looking for a job at a place that was not run by a complete and utter idiot.

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

    Thankfully for the business, in this case, hardware processing power increase rate does outgrow this specific strain of coding idiocy.

  • Your Name (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."
    Though realistically, you might get the counter argument "Well, a new high performance server to run this on costs $ 8000 and having a devver redo this whole thing from scratch with the old invoices in PDF will cost pretty much the same or more - and a new server takes a week to order and get here and two to install test and go live." And yes, if they're the kind of manager that asks "why improve?" then they will certainly look at these numbers.
  • Don Sild (unregistered)

    I don't think 15 seconds waiting time is good for clients. So business needs are not actually met. Normal system would give same information on same hardware in 0.1 seconds. That firm has already 10 years of suffering in growing slower than competition who have faster systems to meet clients needs better.

  • Franz Kafka (unregistered) in reply to Your Name
    Your Name:
    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."
    Though realistically, you might get the counter argument "Well, a new high performance server to run this on costs $ 8000 and having a devver redo this whole thing from scratch with the old invoices in PDF will cost pretty much the same or more - and a new server takes a week to order and get here and two to install test and go live." And yes, if they're the kind of manager that asks "why improve?" then they will certainly look at these numbers.

    Then you get to reply that the fixed arch. is less prone to fuckups and faster/simpler to update.

  • Bim Job (unregistered) in reply to Franz Kafka
    Franz Kafka:
    Then you get to reply that the fixed arch. is less prone to fuckups and faster/simpler to update.
    Yes, I've tried that one. You'd think it's a no-brainer, wouldn't you?

    I'm beginning to think that the world won't be right again before the last middle-manager is strangled with the intestines of the last systems administrator. Sadly, that leaves whole categories of disastrous idiots out there; but we can deal with them later.

  • Franz Kafka (unregistered) in reply to Bim Job
    Bim Job:
    Franz Kafka:
    Then you get to reply that the fixed arch. is less prone to fuckups and faster/simpler to update.
    Yes, I've tried that one. You'd think it's a no-brainer, wouldn't you?

    I'm beginning to think that the world won't be right again before the last middle-manager is strangled with the intestines of the last systems administrator. Sadly, that leaves whole categories of disastrous idiots out there; but we can deal with them later.

    I've met plenty of talented sysadmins. Can't say the same for middle managers.

  • GunstarCowboy (unregistered)

    He also missed out on the third option.

    Assuming that the database was OK, the org could have initiated a project to start a new platform, keeping the old platform for historical reporting.

  • dolor (unregistered) in reply to DilithiumCrystalMeth
    DilithiumCrystalMeth:
    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>

    Ignoring the fact that it takes six months to do it right. It takes 20 seconds, if you're willing to kill a couple of dozen redshirts while doing it and some 200 afterwards when the duct tape fails the next time you make a left turn.

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

    surely a good developer shoudl be hilighting issues before they are noticed by a customer. It's called being proactive! If an issue like this is left unresolved it can infact lead to customer not being able to place orders and I'm pretty certian that woudl harm productivity and revenue.

  • Roberto (unregistered) in reply to spenk
    spenk:
    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.

    The situation described in the second paragraph is caused by the policy stated in the first. A system that will fail a long time from now is considered to "meet the needs", so it is not fixed. By the time the failure becomes imminent enough that managers actually start thinking about it, it has also become impractical to fix.

  • Guest (unregistered)

    Love the ending. I was completley inspired and then it all came crashing down. So much like real life.

  • Balog Pal (unregistered) in reply to dolor
    dolor:
    DilithiumCrystalMeth:
    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>

    Ignoring the fact that it takes six months to do it right. It takes 20 seconds, if you're willing to kill a couple of dozen redshirts while doing it and some 200 afterwards when the duct tape fails the next time you make a left turn.

    For me too it is hard to go by this massive ignorance of the context.

    Cpt. Kirk has Scotty around, who can be safely ordered to make the engines go 20% faster -- he knows to stop at 18% if that is the limit of the push. Also knows all the problems of the tweaks, immediate or late. And if something is truly impossible, he has no problem to say so to the captain, to be just acknowledged.

    Also those orders many times come in a situation when the ship is being shot to particles in a few seconds -- so any risk coming from engine push is not more than that of not trying. Including the possible need to sacrifice redshirts. Or maybe Mr. Spock himself who can work under deadly radiation a little longer.

    however OP is right that our general manager does not see beyond the color of pijamas, and may well think exactly as much -- he orders anything and that is okay, there is no need hom to have the quality of Kirk, even less to have Scotties around. Instead of the carefully selected carrierist yes-people who care as little about anything beyond themselves.

  • Steve H (unregistered) in reply to Management Victim #654,604,223
    Management Victim #654:
    He wasn't acting on management instructions.

    Not once does the article say that.

    The Real WTF is the size of the chip on your shoulder.

  • (cs) in reply to Jeh-fuh-fuh

    Jeh-fuh-fuh

    Better to have stayed anonymous. If switch/casing off of a string, you're not going to get any performance gain.

    Sorry, that's simply not true. Switch statements jump directly to the match with only 1 test. Nested if statements test every condition until a match is found.

    The only time a nested if statement would be comparable to a switch block is if the condition was met on the very first if.

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

    In a similar vein, much like a bad accident on a normal road - if everyone slows down to look at it, everyone grinds to an absolute halt. If everyone keeps going on their way and lets the emergency respondents handle the situation, the accident gets dealt with and folks get to work on time.

    This begs the question, what would happen when there's an accident on the side of the road and there was no such thing as emergency services. Who's the emergency services in the business world?

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

    It's a thin line to walk here. Simon was wasting time when he spent the effort to figure out the problem before an official request was put in. On the other hand, the system is broke when a user has to spend a long time waiting on shopping cart to process every line. This will eventually put an immense strain on the servers as the company's user base grows. Better to fix the issue now then try and fix it when its at its limit.

  • Jim Bob (unregistered) in reply to Bim Job

    Either you can't code PHP (in which case NO ONE CAN), or a PHP coder stole your girlfriend. Cease your hostility, knave.

  • Jim Bob (unregistered) in reply to Jim Bob
    Jim Bob:
    Either you can't code PHP (in which case NO ONE CAN), or a PHP coder stole your girlfriend. Cease your hostility, knave.

    Oops. I hit 'reply' instead of 'quote' to one of Rim Jobs lunatic rants. He is the epitome of the anti-social basement-dwelling geek that everyone despises so. I'm ok with my comment/reply, because almost no one will ever see this, and Rim Job has probably been drowned by his parents by now.

  • NotANumber (unregistered) in reply to Jim Bob
    Jim Bob:
    Jim Bob:
    Either you can't code PHP (in which case NO ONE CAN), or a PHP coder stole your girlfriend. Cease your hostility, knave.

    Oops. I hit 'reply' instead of 'quote' to one of Rim Jobs lunatic rants. He is the epitome of the anti-social basement-dwelling geek that everyone despises so. I'm ok with my comment/reply, because almost no one will ever see this, and Rim Job has probably been drowned by his parents by now.

    I saw this, and I'm offended that you consider me a no one. I am NOT A NUMBER!

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

    NO, he was doing just what he was told: to find out what is slowing down the application.

    He presented the problem and a possible solution to management and they said no. Now how will they explain the slowness of the app to everyday users:

    "Oh, we know why it's slow, just deal with it"

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

    "like making Customer Service refer to soft-copies of invoices instead of direct lookups"

    He didn't say they were soft copies. He said they were PDFs. Presumably the right PDF could be served up in response to the matching invoice number. Then he should have been able to remove all the old IF fail and replace with a single IF (or maybe a DB column) to control whether a given invoice was generated (from new, sane code or new DB tables) or just served from the PDF set.

    "The real WTF is that solving a problem which isn't an actual problem"

    It is an actual problem. Just not the type that is generally recognized to exist by PHBs. At least not until some customer complains and it is probably going to be painful - if not impossible - to fix. In the new, funky enterprise world we like to call this sort of work 'refactoring'. Way back when though we used to call it the 'Right Thing'. Or just, 'Not Screwing It Up'.

Leave a comment on “Immutable Invoices”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article