• SomeGuy (unregistered) in reply to EleganceIsPerformance

    Building a business case for a project like this is fundamental. You need to clarify the risks of the looming train wreck in terms of sales $ lost, lost productivity to address the collapse of the system, etc. In other words, "If we don't do this, here are the possible outcomes."

    All too often, a business case with defensible numbers is deferred, and the project gets rejected.

  • Patrick (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); }

    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.

    That's brilliant! It's like a binary-tree of elseif!

    I'd create a new table to handle the special conditions. As for the invoice data, archived records should NEVER depend on code. Those invoices are something that should be converted into some sort of static format (pdf/rtf/html/jpg/xml/table/emf, take your pick, there's a whole world of them), regardless of the space it would take up. There have been many instances where I've had to rewrite entire modules to prevent this sort of performance rot, and as long as the front end remains entirely unaffected (save for a speed boost), management doesn't really care. Sometimes they don't even notice. Huh. I have a really thankless job. :(

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

    Spoken like someone on the fast-track to management!

  • Patrick (unregistered) in reply to iToad
    iToad:
    This looks like a classic case of Code Cancer.
    This is going on Urban Dictionary, and will eventually find its way to Google.
  • Dave Rodenbaugh (unregistered)

    Sadly, there's still a lot of folks who believe Complexity Demonstrates Intelligence. sigh

  • the beholder (unregistered) in reply to mjm
    mjm:
    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.

    I try not to think like a manager, because I believe it causes brain atrophy.

  • Patrick (unregistered) in reply to SomeGuy
    SomeGuy:
    Building a business case for a project like this is fundamental. You need to clarify the risks of the looming train wreck in terms of sales $ lost, lost productivity to address the collapse of the system, etc. In other words, "If we don't do this, here are the possible outcomes."

    All too often, a business case with defensible numbers is deferred, and the project gets rejected.

    Translation:
    Foresight. Get some.
  • (cs) 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>

    You dinna tell him long it really would take, didja laddie? You'll never get a reputation as a miracle worker that way!

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

    You dinna tell him long it really would take, didja laddie? You'll never get a reputation as a miracle worker that way!

    Ah managing expectations, now that's a useful skill.

  • Code Safety Inspector (unregistered) in reply to iToad
    iToad:
    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.

    If this is code cancer, then the developer(s) responsible are carcinogens. Does this mean we could get the FDA to ban them inclusion in software projects?

  • (cs) in reply to mjm
    mjm:
    ... shit that at least runs.

    This is called diarrhea.

  • (cs)
    Simon found that most elseif() blocks heeded the warning DO NOT REMOVE and DON'T TOUCH UNDER PENALTY OF DEATH and the like
    It's good that the elseif() blocks were self-aware enough to listen to warnings like that. I would be extremely worried if they did not heed those warnings and started committing ritual suicide. But then it would be suicide punishable by death... kinda like jumping before you're pushed.

    Or maybe it was just a matter of the writer not understanding English enough to compose a piece in it... Oh well.

  • (cs) in reply to Management Victim #654,604,223
    Management Victim #654:
    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.

    Probably true, but that doesn't make his actions wrong, nor the actions of management right.

    If he had raised this in a developer meeting, would it have gained project time? Could he have proposed a project to retool the entire shopping cart? I get the feeling there weren't even proper developer meetings in this shop, so probably no way to propose projects other than go to your manager

    Which. Is. What. He. Did.

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

    context Well that was taken out of...

    I'd also point out that "the important thing about invoices is that they must be immutable" means the invoices themselves should be immutable not the code that creates them.

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

    OK. Management is not always as easy as it looks. But: Even if its Boss's decision was right to not to touch the running system, you need to have an idea what you want to do if the system is really slowing down and your customers can not order anything because the transaction runs out before the elseifs are processed...

    Some times managers are very surprised if this problem comes up. They do not remember the day when Simon proposed this two solutions. Instead they make Simon work out another solution which is really ugly again and should be finished by next morning. :-)

  • (cs)

    TRWTF is that invoices SHOULD be immutable. Generate once from data. Then they should never be allowed to change, so you must store them in an unchangeable format. They just should be static no matter what. They are historical documents now. Regenerating them each time from scratch just to view them is incredibly moronic and too easy to break.

  • Sean Hunt (unregistered)

    The solution here is obvious. Rather than keep all the elsifs like that, replace it with a database table that looks up an order ID number (or a range, as in this case) and returns multiple results, in order. Then simply loop through them, eval()ing the result each time to determine if they match an additional criterion (like the TLD shown in the example). If not, keep moving.

    This way you only execute all the branches that might conceivably match.

  • Pedant (unregistered)

    My normal approach is to raise a defect in the tracking system "System beginning to run slow, investigate and resolve" Then assign it to manager and wait for it to be dished out..

  • Daryl (unregistered)

    Totally agree with the manager with this one. And I've experienced this so many times.

    • why would I want to upgrade to sql server 2008 from sql server 2000?
    • why should we want to fiddle around with nearly 150 tables in our database to make things smaller?

    Most of the time, these situations involve coders dealing with what they deem "inelegant" code, and itch to deliver their own genius solution to the problem. However, half the time it breaks the existing solution, and causes more problems.

    So what if its going slower and slower? Something that works is better than something that's broken. Worst case scenario is you'd need a better server to deal with the increased processing.

  • Bart (unregistered) in reply to Daryl

    I guess if your clients are fine that you are hosting their application on NT and SQL 6.5 on a $15,000 dollar server then, yeah, sure don't bother.

  • Trogdor (unregistered)

    Another WTF is that the story seems to indicate that the manager and the coder don't respect each other. A company is more than a revenue machine; it is people!

    They both need to sit down together and work out the whole situation. The company doesn't benefit when good coders leave; coders don't become better coders by getting angry at management.

    People aren't cogs.

  • Patrick (unregistered)

    Simon definitely gave up too easily. The fact that he left the room "defeated" when asked why they should fix the code would only show the manager that he doesn't really believe it's such an important issue, even if he does. So yes, when the whole thing collapses no-one's going to remember that he tried to, because he didn't.

    BTW: http://www.urbandictionary.com/define.php?term=Code%20Cancer enjoy.

  • Patrick (unregistered) in reply to Patrick
    Patrick:
    uh... give it a day or so.
  • David (unregistered) in reply to Management Victim #654,604,223

    Whether it's affecting revenue or not depends on whether it's being annoying to customers, which isn't something listed. The story doesn't say exactly what was happening, only that the software was slow and getting slower. If it gets too slow, the company has to pay for extra servers, which isn't the end of the world, but an expense nonetheless. What is clear is that any problems were only going to get worse, and probably would wind up affecting revenue and productivity.

    It may also be that Simon had leeway for some initiative in his job. Not everybody is a code slave chained to their computer and programming to the beat of a large drum, you know. Not everybody has their schedule completely full of tasks they are ordered to do.

    So, the WTF was not that management didn't go with Simon's solution (which may have been the right thing), but that they didn't see any need to improve the situation. This may have been one of those companies that thinks that looking ahead two quarters is long-range planning; certainly one with a strategic vision would have made some plan to replace the mess.

  • Andrew (unregistered)

    How about parallel processing?

    Split the code into 4 and run each request concurrently. If there's no result for server 1, look at already completed result for server 2, etc.

  • Nick (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."

    Don't developers have something like "Must be proactive" or "Must show initiative" in their job descriptions? If I hadn't done a lot of "hobby-jobbing" shell script work, I would spend ten times longer checking servers, running reports, etc. Time that I now spend doing actual productive work.

  • Shinobu (unregistered)

    All the elseifs may be a WTF, but not nearly as large a WTF as wanting to replace the existing (working, albeit slow) invoice lookup infrastructure with a bunch of PDFs. That, my dear boy, is not an improvement.

    • Why have you put piranhas in the swimming pool?
    • To keep the otters away.
  • Franz Kafka (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

    1. is wrong as hell. cpu speed isn't doubling every 18 months anymore and irrelevant - tossing hardware at bad architecture is a bandaid on a GSW. fix you goddamn code.

    2. another bandaid. What's so hard about loading offers from the DB?

    BentFranklin:
    TRWTF is that invoices SHOULD be immutable. Generate once from data. Then they should never be allowed to change, so you must store them in an unchangeable format. They just should be static no matter what. They are historical documents now. Regenerating them each time from scratch just to view them is incredibly moronic and too easy to break.

    My current work does this. There's some level of justification - things can change, given that it's not a thing in a box, but a service at a future time, but we don't store the thing in any one place. It's regenned every time.

    Andrew:
    How about parallel processing?

    Split the code into 4 and run each request concurrently. If there's no result for server 1, look at already completed result for server 2, etc.

    How is this simpler than loading product info from the DB? Store historical data in a denormed form based on copies of what the data was at time of purchase and hold on to it for 5 years, or whatever required time period it is.

  • c0rnh0l10 (unregistered) 
    
+------------------------------------------------------+
| offer_id | offer_from |  offer_to  | offer_detail_id |
+------------------------------------------------------+
|        1 | 2009-01-01 | 2009-02-01 |               1 |
|      ... |    ...     |    ...     |             ... |
+------------------------------------------------------+

SELECT * FROM offer WHERE
 (offer_from IS NULL) or (offer_from <= NOW()) AND
 (offer_to IS NULL) or (offer_to > NOW())
  • c0rnh0l10 (unregistered)

    Oops ... I mean:

    SELECT * FROM offer WHERE
 ((offer_from IS NULL) OR (offer_from <= NOW())) AND
 ((offer_to IS NULL) OR (offer_to > NOW()))
  • (cs) in reply to Matt
    Matt:
    SenTree:
    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.
    Matt:
    context Well that was taken out of...
    Most people read the OP and the replies, so are aware of the context. Quoting massive blocks of text which most people will skip seemed wasteful when all I wished to do was highlight some points.
    Matt:
    I'd also point out that "the important thing about invoices is that they must be immutable" means the invoices themselves should be immutable not the code that creates them.
    Oh gee! I hadn't realised that. No, wait - the story implied that invoices were regenerated on the fly, which was why the old code could not change.
  • Andrea (unregistered) in reply to Management Victim #654,604,223

    Keeping a system like that in place means losing money, and likely in a way that is not detected by ordinary means. What management is supposed to be payed for is, among other things, evaluate situation like these. Saying "it works, there's no need to change it" really means giving on evaluating the pros and the cons, so giving up on doing your freaking job. The real WTF is that, day after day, this kind of thought becomes more and more accepted, even by programmers.

  • z f k (unregistered) in reply to Dave
    Dave:
    [...]"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 answer "Well, 2012 is the end of the world, so why bother?" :D

    CYA

  • z f k (unregistered) in reply to Jim
    Jim:
    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.

    Well, maybe the language lets you conditionally include piece of code (php has include() include-once() ). This way, the old system (with its 16kloc) is loaded only when necessary.

    CYA

  • Anonymous Cow-Herd** (unregistered) in reply to halcyon1234
    halcyon1234:
    if ($invoice->date < $revisedBySimonDate) { $oldClunkyElseifSystem->Generate($invoice); } else { $newBeautifySystem->Generate($invoice); }

    What happens if ($invoice->date < $revisedBySimonDate) is FileNotFound

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

    If it's getting slower at a linear rate while machines are getting faster at an exponential rate, you just don't have a problem.

  • (cs) in reply to Bart
    Bart:
    I guess if your clients are fine that you are hosting their application on NT and SQL 6.5 on a $15,000 dollar server then, yeah, sure don't bother.

    I for a fact know that about 35-40% of my national electricity grid is controlled by a machine running NT SP3 because the software doesn't work on newer systems and the original developer is gone since 2000 and nobody knows what magic the application exactly does. Yes electricity production and trading (and thus pricing formulas & related math) are intertwined. They are lucky it got converted from Guilders to Euro's before the developer left.

  • (cs)

    So, to summarize, we have

    1)_a group of people who based on incomplete data can conclude that it would be sheer madness to replace a system which works under any cirmcustances becuase new code must a) be buggy or b) needlessly expensive

    1. a group of people who assume that manangement cannot possibly understand any issues related to the real world and thus must be wrong in their evaluation

    Not to mention the non-mutually exlcusive group of people who thinks Simon was an idiot for giving up based on the conclusion of an article which is meant to be humorous.

    Perhaps Simon was an idiot. Perhaps Simon quit. Perhaps Simon went on to implement a new system in his own time which he then sold to management for mucho bucks when the old one collapsed.

    TRWTF is...well us.

  • (cs) in reply to Planar
    Planar:
    If it's getting slower at a linear rate while machines are getting faster at an exponential rate, you just don't have a problem.
    That depends on the slopes of both. If the machines are doubling in speed every 18 months, but your process takes 10% (non-compound) more work every single month, then in 10 months time it will be taking twice as much work, while the machines won't yet be twice as fast.
  • Old Coder (unregistered) in reply to Management Victim #654,604,223

    @Management Victim,

    You are dead on. I have found that in most cases, our aspirations to do code "the right way." Do not align with business need. I have come to the realization that my perception of "quality" is usually not the business's.

    Businesses need functional systems. They usually don't care if that functional system is a rat's nest or a state-of-the-art IOC-driven, unit tested wonder. If it is not perfect, they still make money. When it gets unbearable, they gripe and pony up for a re-write.

    In the spirit of full disclosure, you can inform the business people about quality, flexibility, maintainability, scalability, and all of the "-ilities." You can explain about technical debt. But in the end, debt of all kinds is a tool used by companies. So, many, many choose to operate in a perpetual state of technical debt, because despite poor internal quality, the systems perform well enough to allow the business to make money.

    I have spent 25 years writing software, constantly studying techniques, technologies, and processes. For about 20 of those years, I was frustrated by the "short-sightedness" of the business people and my inability to find a home somewhere where they "do it right."

    I found that I had to let go. Be a good influence when I can. Fully disclose risk without being "doom and gloom." And, build the best systems I can within the business need and constraints. I am a lot more relaxed now. :-)

  • Franz Kafka (unregistered) in reply to Planar
    Planar:
    Rootbeer:
    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.

    If it's getting slower at a linear rate while machines are getting faster at an exponential rate, you just don't have a problem.

    Two unwarranted assumptions: since the act of adding an item is o(n), pricing is an n^2 op (yes, the catalog size is a variable), and there's no reason to believe the new things are being added linearly. Second thing is that processor speeds aren't going up nearly as fast as they were before.

  • Level 2 (unregistered)

    TRWTF is that the system needed to recalculate old invoices. Compute the invoice once and store it in the database.

  • regeya (unregistered) in reply to Level 2

    Yeah, same here. As it said in the article, one of the options was to export PDFs. Sounds like the best plan, since they shouldn't have to be recalculated as many people have pointed out.

    The other RWTF is the sheer number of people defending the practice of keeping slow, bloated code around for no better reason than that management is too lazy to crunch the numbers on a simple cost-benefit analysis. Simon, here's my summary on what you should have thrown at your manager: If we export PDFs, we export them once, instead of recalculating every time and tying up the equipment every time. Further, by removing all the conditional code, the app runs faster by not having to process all those conditionals every time the script runs, which means we can put off a hardware upgrade.

  • Jeh-fuh-fuh (unregistered) in reply to eeth
    eeth:
    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...

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

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

    I'm afraid our "no drinking on the job" policy prevents me from doing that.

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

    Seems like a long-term solution as well. I doubt the else-if blocks are growing at a pace that can outstrip Moore's law.

  • Nick (unregistered) in reply to iToad

    Cancer is like O(n^2), this is only O(n), right? And if it's worked fine for 10 years, performance-wise it apparently isn't a worthwhile problem to fix now or let-alone for another decade.

    If he wanted to fix it eventually, it's not like they (are going to|can) change how they do things, so porting 10000 vs. 10010 statements of code to X is not any different.

  • (cs) in reply to Matt
    Matt:
    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

    And here's TRWTF: Many admins would think the boss's question was rhetorical, just like you did.

    It's not. It NEVER is, if the boss doesn't OK the work without an answer. NEVER, EVER, EVER.

    Don't believe me? Go look up the definition of rhetorical.

    Yes, the question should've been rhetorical, but it obviously wasn't.

  • (cs) 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 anywhere 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>

    FTFY. Energon cubes are from Transformers, Dilithium crystals are from Star Trek.

  • Max (unregistered) in reply to halcyon1234

    Too.. much.. sense.. head.. explode..

Leave a comment on “Immutable Invoices”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article