• (nodebb)

    I don't understand the logic behind purchasing ERPs like Dynamics AX, etc. Huge upfront and yearly license costs, huge upfront customization investment, continuous headache of "who supports what" (client vs vendor) and "is it possible to customize this or that", etc. It's like corporate decision makers believe in the god of ERP, who punishes those who try to implement a custom solution in-house with eternal hell fire. It has to be faith and fear, because I'm struggling to find logical answers.

  • Hanzito (unregistered)

    Dvorak or death!

  • (nodebb)

    A special shoutout to how they list off their alphabet by just following the QWERTY keyboard layout. That, itself, is the real WTF, as we all know the correct layout should have been "pyfgcrlaoeuidhtnsqjkxbmwvz".

    But but but ... but... those letters are all over the place on any normal keyboard. And any fule no that the correct order is "azertyuiopqsdfghjklmwxcvbn".

  • (nodebb)

    I'm going to bet that the method name modifed is like the old auto-wireup events under Visual Basic.

    There is some object, probably a UI screen, that when it is modified by, e.g. user input, automatically calls an event handler that must be named modifed and is somehow textually tied within the dev UI to the rest of the definition of that screen and its functionality.

    So if you have 50 screens, you'll have 50 modified methods. And 50 updated methods. And 50 saved methods. etc.

  • retsep (unregistered)

    "wo do some string munging" really sounds like some vuhdoo stuff.

  • Kindadarii (unregistered) in reply to WTFGuy

    As a (former) AX developer, I believe this is exactly the case as I recall. It's not a dirty check at all, but an event handler when the record has changed. In this case, it's assigning a (probably non-standard) field with a value from a lookup table.

    AX has a lot of WTFs. This... sadly... is not one of them.

  • Scragar (unregistered)

    If there is a record, wo do some string munging, ...

    Typo on "we do"?

  • (nodebb)

    After reading this code, I feel postprefixual.

  • smetzger (unregistered) in reply to Mr. TA

    Either...

    1. Bought a long time ago when the ERP was simpler and the business processes were simpler or
    2. ERP vendor has a really good sales team.

    But, I agree hire a few full stack developers and just write your own custom internal solutions.

  • TheCPUWizard (unregistered)

    "we might have made it dirty just by validating it" -- And that is the EXACT reason for doing this....

  • Deeseearr (unregistered) in reply to Scragar

    Typo on "we do"?

    Just yo do that wo do that yo do so well.

  • Conradus (unregistered)

    Write your own ERP solution? Write your own solution for a standard problem that has doubtlessly been solved hundreds if not thousands of times before?

    No, buying an ERP solution is the right way to go. The trick (and it is a trick) is not to buy a bad ERP solution. With the buying decision in the hands of managers who don't really understand how it all works, this can become quite hard.

  • (nodebb)

    I've seen this kind of code a lot. I've written a fair bit of this kind of code: you need a new feature, there's no good place to hook the functionality in, so you find a place that touches the right part of the lifecycle and just wedge this into there. Voila, feature works, release it, and users are happy. Technical debt becomes a problem for future you, or more likely, your successor.

    Are you me? Or my colleagues? I sometimes feel like our whole project operates like that, as refactoring in the absence of test coverage is almost impossible.

  • (nodebb)

    I get the headache of ERP's, but RYO is worse. I've been trying to integrate with our #1 supplier for a year. They have a custom written "ERP-ish/Accounting-ish" solution. Integrating with them has been hell. No industry standard protocols work. We've just made the decision to move our business to another vendor, specifically because of this. We've loved their service, their willingness to work with us, their pricing, but their custom tech has just lost them a $100M account.

  • (nodebb)

    ERPs do a lot out of the gate (or at least the sales team will be happy to sell you a pre-configured option), and they handle data from (in theory) everywhere, so you can look up coupon redemptions by phase of the moon, server load, and employee bonuses. I think the idea of "it handles anything, and it's already configured to do most of what we do" runs up against it being an inner platform.

    It's great when it works, but you do not want to see how the sausage is made. And the audience for this website is the sausage-grinders.

  • xorium (unregistered) in reply to WTFGuy

    Usually there is a default for such methods, which you can override if you need to do something special. So no need to have 50 of each.

  • LZ79LRU (unregistered)

    The reason companies go for ERPs instead of rolling their own are many. But they all boil down to the fact that a solution made by professionals whose only job is to make such solutions, maintained by professionals whose only job is to maintain such solutions and hosted by a company whose only business is that specific solution and who thus have a financial incentive to provide quality service in perpetuity rather than for how ever long it takes for old Bob who wrote the code and newer left any notes to switch jobs or retire sounds very appealing when you put it like that.

    Now consider that most companies are not IT shops and that therefore any in house solution would be mismanaged, mislead and very likely mismade from day one and you can see why

    And we need only remember all those ExcelERPS and homemade cludges we've seen in our lives to know its not false either.

    Really, the problem with software is that we are usually the ones to fix it when it goes wrong. Therefore we usually only see it at its worst. So we naturally assume it's all like that all the time. Where as in reality it mostly works most of the time. We just don't get to see that.

Leave a comment on “Prefixual”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article