- Feature Articles
- CodeSOD
- Error'd
-
Forums
-
Other Articles
- Random Article
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
As does the frist!
Admin
So they have an unversioned API? This can't be the first problem with that approach...
Admin
Been there, done that, was still around to clean it up finally :)
Admin
@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.
Admin
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.
Admin
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.
Admin
Don't forget the inability to fix bugs, because someone out there might be depending on the buggy behavior.
Admin
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.
Admin
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!
Admin
Maybe, but per WTFGuy's comment, "chopping block in the next release" may be way too optimistic
Admin
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.
Admin
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...
Admin
Is it broken? A performance hog ? No, then leave it alone.
Admin
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.
Admin
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?
Admin
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.
Admin
... 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.
Admin
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.
Admin
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%.
Admin
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.
Admin
the UK Covid19 Test & trace program per chance :-)
Admin
Well if you for the last two years had to do 4 tabs to get to the right field and suddenly it’s only three. That takes a while to get out of your muscle memory. Just remap save in your Favorite IDE from ctrl-s to Ctrl-t and see how you fare
Admin
We have this in our in house project. We must absolutely avoi the code crashing for customers (reasonable) and we have no semblance of useful automated testing (bad) combined with really bad internal data layouts (e.g. plain integer arrays containing data and metadata mixed in a manner, that is only documented by how the code uses them).