• Preposter (unregistered)

    As does the frist!

  • pudin9 (unregistered)

    So they have an unversioned API? This can't be the first problem with that approach...

  • David Mårtensson (unregistered)

    Been there, done that, was still around to clean it up finally :)

  • WTFGuy (unregistered)

    @pudin9: Otherwise known as an add-only API. BTDT.

    Nothing prevents them launching the first versionable version of their API now. Except for the size of the installed base vs. their new customers. In Corpworld a lot of software, especially things like customizations to workflows is "build once, deploy once, use forever". Totally the opposite of the "continuous versioning, continuous improvement, continuous churn" model of modern websites and modern apps.

    So great. Octavia's PHBs approve doing a solid refactoring into APIv2. And officially deprecate APIv-unversioned. They just started a 20 year tortoise race before enough of their customers on that date have moved to v2 that they can withstand switching off v-unversioned. Obviously you can incentivize them moving sooner by putting all your cool new functionality only in the V2 API. But expect plenty of pushback & threats to drop your product if you do.

    Bottom line: A sizeable fraction of legacy WTFs are that way becaase it really is the least bad option on offer. Ghastly though it may be.

  • Brian (unregistered)

    Ah yes, the old "we can't change that because some customer somewhere might still be using it". My favorite instance of this one was when I was working on some code that generated an Excel file. No matter how ugly and horribly-formatted that file might be, any updates to the surrounding code had to maintain it exactly as-is. Because, of course, there were customers who used our Excel files as inputs into their own workflows, and having one cell out of place would inevitably cause someone's carefully crafted house-of-cards formula to come crashing down.

  • Casey McD (unregistered)

    In C++ you can add a parameter with a default value, so it doesn't break any existing code. Looks like they also added it to C# in version 4.0.

  • (nodebb)

    Don't forget the inability to fix bugs, because someone out there might be depending on the buggy behavior.

  • Jay (unregistered)

    Could they release a note or warning that said method will be deprecated or changed in the future? This will at least remove some liability, document the problem, and prep the method for the chopping block in the next release.

  • JimJ (unregistered) in reply to Casey McD

    That is true but default values for arguments do not fully protect from breaking compatibility. First, this would be only compatible for source code, but not binary-compatible, so the app won't be able to work with the assembly other than it was compiled against. But OK, this is a rare case anyway. But there is always a chance that someone derived from our class and added another method overload that happens to have exactly the same set of arguments, and after the upgrade this stops compile or worse silently starts using the wrong overload because CLR decides there is a method that suits better (if type casts are involved - say, from int to decimal). Such a rich ground for WTFs!

  • (nodebb) in reply to Jay

    Maybe, but per WTFGuy's comment, "chopping block in the next release" may be way too optimistic

  • MiserableOldGit (unregistered) in reply to Barry Margolin 0

    Sadly it's a real phenomenon.

    Closely followed by the one where you discover that, although the data is collected, calculated, worked on by several members of staff, reported, fed out to partners, nobody has actually looked at or used the end result for years because it ceased to be needed or relevant following some project and the business analysts didn't notice.

  • DQ (unregistered) in reply to MiserableOldGit

    That is so true. I remember that some fifteen years ago (OMG, I'm getting old) I built a tool that generated a dozen different reports every month. Untill one day my boss asked if I could create a report with certain KPI - KPI the tool had been spitting out for years! So the next month I updated the parameters in the tool and except for two reports I knew they were using had all the rest move to another location. Nobody ever asked about them...

  • john (unregistered)

    Is it broken? A performance hog ? No, then leave it alone.

  • Old timer (unregistered) in reply to Casey McD

    Looks like they also added it to C# in version 4.0.<

    Finally upgraded to match a feature of VB6, which C# didn't have because c doesn't have that feature.

    Now if only they would add parameterized array limit declarations. [1..31], or [start_index to end_index]. Second only to memory-managed string objects as the single feature which removes most bugs from programs.

  • Moss (unregistered) in reply to Old timer

    What's an "array limit declaration"? And what's a parameterised one at that?

    The [x..y] syntax looks like ranges in C# 8.0* but I assume you're talking about something else?

    • https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-8.0/ranges
  • (nodebb)

    Now if only they would add parameterized array limit declarations. [1..31]

    But then it wouldn't be "a real man's language". That seems to be the excuse for not adopting VB's less error-prone event delegate invoking keyword RaiseEvent.

  • shcode (unregistered)

    ... she could at least replace the body of the function by string.padleft and a disgusted comment explaining why it can't be removed/renamed/anything.

  • (nodebb)

    Ah, customizations! It happens I have spent several weeks over this year mangling the company data. For us, customization is absolutely key to business and it clearly shows in metrics such as: A- ~20% of systems using customization (as opposed to the perception of 2/3)

    B- Taking away relevant customers A and B, customized systems made less than 1% profit, often finding their way into the red because...

    C- Without considering A and B, customized systems made for nearly 70% of incidents, unplanned costs, workflow destruction, escalated support calls you name it. They devour margins super extra fast.

    C-bis - note: I have not even attempted to assess the cumulated opportunity cost involved.

    D- The true icing on the cake: 3 customizations out of 4 are just a label being renamed. I have heard 'data-driven' has a different meaning nowadays.

  • Sole Purpose Of Visit (unregistered) in reply to UserK

    It's probably too late for this, but have you considered applying interfaces aggressively over your core product?

    It's what we do (VB.NET interfaces used for C#.NET specialisations). There are obvious issues (what with the fact that interfaces are pretty much set in stone, unless you literally punch the product manager/boss in the face).

    It's a pretty good way of customising various "refatorings" like "renaming a label," though. And in theory you could just build a "shim" over the base product, using the Decorator Pattern (ugh, GoF) for silly individual customer requirements.

    Yes, build cost, deployment cost, support cost, etc. But at least you don't spend most of your time adding stupid switch statements to your base product, simply in order to support the 1% or 2%.

  • 🤷 (unregistered)

    This reminds me of a story I heard, where a developer had the audacity to remove a checkbox from the GUI of the product they were shipping. That checkbox had no purpose. It just sat there on the GUI. It's status was never checked, it wasn't referenced anywhere in the code (except of course in the GUI.Designer.cs), so it wasn't set by some DB method either.

    That developer got some angry emails from customers who accused him of totally breaking their workflow because they somehow relayed on that checkbox being there.

  • ipguru (unregistered) in reply to Brian
    Comment held for moderation.

Leave a comment on “Prepend Eternal”

Log In or post as a guest

Replying to comment #:

« Return to Article