• Sigako (unregistered)

    We have an idion: "Miser pays twice". Or thrice, in this case. Not sure about proper English analogue.

  • Sigako (unregistered) in reply to Sigako


  • Prime Mover (unregistered)

    So, as long as Reese got a sizeable slice of that initial consultation as compensation for having wasted his evening by returning to the office, all is sweetness and light, yeah?

  • 🤷 (unregistered)

    I'm not sure if I like this recent trend of stories concluding with a happy ending.

  • Foo AKA Fooo (unregistered) in reply to 🤷

    Plot twist: The different company Reese joined was actually Initrode, and he knew very well the horribly expensive demo still lived on because he had to maintain it.


  • Tom (unregistered) in reply to Sigako

    Never heard that one, but I like it. I've also heard "Buy cheap, buy twice"

  • Hasseman (unregistered)

    Penny wise, pound foolish

  • (nodebb)

    The real WTF here is that you have a client who actually needs the ERP and is willing to risk using a demo version, as opposed to most companies I've seen where the ERP is used, but is not really needed, is hugely overpriced, unreliable with weekly problems, extremely slow and terribly designed on the backend.

  • 516052 (unregistered)

    Quite. Like, I get the feeling that in a lot of places ERPs and the like are more of a status simbol / right of passage for companies than something actually useful.

  • 🤷 (unregistered) in reply to Foo AKA Fooo

    Plot twist: The different company Reese joined was actually Initrode, and he knew very well the horribly expensive demo still lived on because he had to maintain it.


    Yes. Thank you!

  • Ollie Jones (unregistered)

    We love to slag "enterprisey" software. I wonder if it gets so messed up partly because sales people don't say these words more often:

    "This is what we have to offer, and this is the price. We have many successful customers. We'd love to count you among them."

    Of course a sales person should qualify the customer before convening a meeting with tech people. If they don't have the budget for the project, well, bye.

  • (nodebb)

    The real WTF is that Reese's company had a business model where they charged for the client software, but access to the server was free and unrestricted.

    Either that or they separately licensed the server access and the more or less mandatory client software, in which case they are guilty of sharp practice since they clearly failed to tell Ed the real full cost when they originally sold him the service.

  • PSimpson (unregistered) in reply to Sigako

    Something like "Penny-wise but pound foolish." would pretty well cover it. Or, "Spend a dollar to save a penny." The concept is universal, so I'd be surprised to find a country that doesn't have a similar saying.

  • Canthros (unregistered) in reply to Ollie Jones

    Sales-driven development is the cause of many woes and hardships, in my experience.

  • The Dave G (unregistered)

    It's too early for deja-vu.

    In the 90s we started getting calls from clients (wtf #2, devs were the support desk) about problems with an app our company had installed on their PCs. Call the "<something> Prototype". We had no clue what they were talking about. Turns out that a sales rep had had our custom group, whose job was to create custom reports, create a demo app for a client (wtf #3) . And had installed it. And never told us, much less provided any training, documentation, or even source code.

  • Scott (unregistered) in reply to Sigako

    I've heard, "It's the cheap person who spends the most."

  • scriptninja (github)

    To "miser pays twice;" "buy cheap, buy twice;" "penny wise, pound foolish;" and "spend a dollar to save a penny" I would like to add "expensive discount;" although I've only heard one person say it I thought it was apt.

    I thought I was trying to remember another one that would apply until I realized I was thinking of "more haste, less speed," which is a similar concept but...well, not money.

  • (nodebb) in reply to Foo AKA Fooo

    Much better....perhaps the next step is that his former company decides that Reese's quitting to work for a customer in a way that directly competes with their consulting services is a violation of Reese's employment agreement.

  • TS (unregistered)

    See also: The Sam Vimes "Boots" Theory of Economic Injustice (which relates to inability to pay more, rather than unwillingness).

  • DQ (unregistered) in reply to PSimpson

    Actually, I can't think of a similar saying in Dutch. It's probably me.

  • Vilx- (unregistered)

    Ha! That's my story! Yaaay! :) A lot of artistic liberty with the details, but the core wtf is correct. :)

  • Bruce W (unregistered) in reply to scriptninja

    "spend a dollar to save a penny"

    At a former company we modified that to "Spend $1,000 to save a penny". Yeah.

  • MiserableOldGit (unregistered) in reply to scriptninja
    I thought I was trying to remember another one that would apply until I realized I was thinking of "more haste, less speed," which is a similar concept but...well, not money.

    Yeah, I suppose "a stitch in time saves nine", "act in haste, repent at leisure". Not exactly the same, but interesting. Perhaps these ones belong in one of the technical debt stories!

    Although as someone else said, TRWTF here seems to be 2 or 3 things to do with the business model.

  • Vilx- (unregistered)

    The business model here is one of the artistical liberties. Or maybe I did a poor job explaining it when I submitted the wtf. The main erp application consists of a central DB (hosted on the client's servers; we never were in the business of hosting) and a desktop application which connected to the said db. I don't remember how the licensing worked but I think the price depended both on seat count and enabled features. But of you wanted to access the whole thing programmatically... Well, you could try rummaging around the labirintine DB yourself but good luck with that. The standard approach was a "server" application which also connected to the DB and which then offered an API over a homebrew TCP-based protocol. There were client libraries both in Java and .NET. And this is the option wich sets you back by several K of currency. (The more modern REST API was in the works back then, but would have ultimately cost the same). Or the ancient OLE "api" which depends on the desktop erp application being present, because it actually spins that up as an OLE server (or something) and has all kinds of issues. This required no additional licenses (well, except for a standard erp app seat which they already had).

    They chose the OLE route because of the price I think, but what followed then was a weird reluctance to even touch the example code I provided them with. At their request, I even split it into a library (which they could integrate in their own product) and a demo app for said library, but they only used the demo app... in production... I could understand not wanting to have any liability if it didn't work well, but this wasn't officilly supported by us anyway. I don't know what their reasoning was.

  • Old timer (unregistered) in reply to Vilx-

    Getting the source code and a having it refactored means that, if your company fails, they could move support to a different external contractor.

    The weird reluctance to do their own support, maintenance, and programming isn't weird, unless you're a programmer. If you're a programmer, not doing programming looks weird.

  • Vilx- (unregistered) in reply to Old timer

    But they were a software development company, specializing in POS systems. And they had a client that was using our ERP. And that client wanted to get some data from their POS system int our ERP system. When they came to us it was specifically to figure out how to integrate the two systems.

  • WTFGuy (unregistered)

    Sounds to me like they were as bad at being a POS company as y'all were at being an ERP company.

    Either that or their whole tech stack and yours had about zero overlap.

    Or, most likely of all, the salesmen ran both companies. Badly.

  • roantho (unregistered) in reply to DQ

    In dutch it would be "Goedkoop is duurkoop". Losely translates to "Cheap is expensive."

  • Cheats Never Prosper (unregistered)

    Looks very much like the client wanted to get the "demo" and use it, free, instead of buying anything.

    Maths is too hard for people. So they looked at the Day 0 cost = nothing, ignored Day 1->N costs, and set about stealing. Thousands saved, hurrah! Minus ten points for honesty.

    WTF: they were given the source code that did the necessary magic; they could have developed this themselves and never need to pay a dime more. However, as maths is TOO HARD they chose to pay these invisible, mounting costs instead. More pennies saved, more thousands spent.

    It is not the business of a business to make money, otherwise they wouldn't get into these ridiculous situations. It is the bueiness of every employee to mess around, creating problems for the future, while failing to resolve the problems of the present... most of which are self-inflicted - or - self-intended.

  • 🤷 (unregistered) in reply to Cheats Never Prosper

    Looks very much like the client wanted to get the "demo" and use it, free, instead of buying anything.

    This mindset seems to be very wide spread. I just got reminded of this: At my old company management was too cheap to spent 200€ to buy a licence for a chat bot application (which was used as one of the core features on the company's website!), and they didn't want to have a backlink to the chat bot company either, so they had an intern write a database event that would remove the backlink part from the database every time there was an update. And this is AFTER the whole IT department said: "You know that this is against the EULA, right?" But why listen to IT people.They don't know what they are talking about.

    But this didn't really surprise me. That company was also too cheap to spent money on more than one licence for Visio. Those are like 17€ per licence.

    Also of note, since June 2020 the "chat bot company" is in liquidation. No wonder when others don't pay to use the product.

  • 516052 (unregistered)

    To be fair, the concept of paying much more later over time instead of a little bit up front is a cornerstone of modern economics. Yes it's stupid and wasteful but it's also essential and ensures you can get your shitty plastic phone that spontainously combusts, your holliday on a covid beach or that overpriced car with features you'll newer use that can drive faster than you'll ever be allowed to today and for the price of a house back 50 years ago today and without having to think about the fact you are turning your self into a debt slave to a bank.

    So is it really that shocking when buisinesses take up the same model?

  • Vilx- (unregistered) in reply to 516052

    Borrowing money CAN make sense, if you use that money to make even more money.

  • IPGuru (unregistered) in reply to Sigako

    in english we have a couple "do things on the cheap & it will cost you dear" or "By Cheap, Buy Twice"

  • (nodebb)

    This sounds very familiar.

    The company I was working for up until last year had a specialized bit of hardware with an old but pretty decent API - basically XML over TCIP/IP pipe & some UDP broadcast for messages. Local company using our hardware, changed POS vendors to a new company based on the opposite side of the world. We provided API docs, hardware, sample code and offered support to the new POS vendor. They seemed pretty arrogant, had done lots of integrations and didn't really need our help.

    They did get the integration going within a couple of weeks, which was about right for other vendors, but far less questions than normal. System rolled into production, and seemed to work OK, but a few niggly bugs that client needed to get fixed. Our support team blamed the new POS vendor (as the old system didn't have issues), the new POS vendor blamed our code. I got called into to investigate; starting with quick check of software versions to make sure our test rig == production, and to pull logs from production sites

    That's where the problem started; POS vendor didn't know the version of the DLL that controlled the hardware as 'it was our shitty code'. and no logs. We didn't supply any DLL with the API - it was just XML over a TCP/IP link and was supposed to be language and platform agnostic.

    Turns out one of our helpful devs (who had left the company since), had replied to a Skype message from the a POS vendor dev and gave them a single C++ file with some sample/test code, and then on request compiled it for them. They turned it into a DLL and wrapped the POS interface around it, so the entire production system was now running on an undocumented bit of sample code (not in git) which did some of what the API was supposed to implement. No logging, no test scripts, no version numbers etc.

    We wouldn't support it, so they found the source (in a Skype message) hacked it a little to fix the worst bugs and AFAIK it is still in production.

  • ItsNeverDoneThatBefore (unregistered)

    In the 80's, was supporting a dongle-protected single [DOS] PC engineering app (LAN version was much more expensive and used different protection). The dongle was checked, each time a sub-program loaded and, one day, a client reported problems which seemed like intermittent dongle failure. Nipped down to site (no remote diagnostics in those days!), engineering manager (no IT departments either!) showed me the set-up and all seemed fine, with the dongle plugged into the PC. Left site and was just driving off when I realised I'd forgotten something, so, went back for it. Engineering manager was in another meeting but his secretary took me back to the PC....where I promptly spotted my dongle, now taped to the wall, plugged into a home made splitter box with cables running to the 'offending PC' and 3 other PC's all running client-made copies of our software....which, of course, meant that our poor old dongle was getting multiple 'are you there' requests from the various PCs which, periodically, would conflict with each other and throw the observed errors....cue much spluttering and embarrassment when the manager returned to his office and found me sitting in a chair staring pointedly at the dongle taped to his wall, followed by a fairly large time & materials bill for my visit plus an invoice for three more copies of our software....users, doncha just luv them?

  • Some Ed (unregistered)

    I'm continually amazed by the number of times somebody on my team (we're all programmers these days. Some are CS, some are CEE, but we all have some programming degree) has responded to a question from my management about how some third party application we used worked with, "I don't know. But it's certainly not how they've documented it.", and then went and looked at the application and found that it happened to be using some scripting language, such as Perl, Python, or Ruby.

    Most of us did coursework in Python, many of us did coursework in Perl. Some did coursework in Ruby, and a couple did coursework in TCL. I graduated before my school offered classes using any of those languages.

    It's generally been pretty easy to update the vendor's code in these cases to something that works more like we'd like. I'm aware that there can be legal repercussions of doing this, but most of those only attach if one attempts to then distribute said updates to other organizations.

    If you continue to pay them as you are and don't distribute your changes to anyone besides them, ... I'm sure there's probably somebody somewhere who would complain about that, but so far, I've not had any company send a cease and desist letter. There was, admittedly, a director of engineering who vocally objected to my statements of having done so, on a phone call with the CEO of his company on the line. But that company clearly didn't agree with him, because that company fired him less than a week later, and the CTO asked for my fix around the same time. The CTO didn't mention firing the guy, but did apologize for the lack of QC that had made my fix be necessary, and that director had been responsible for that QC gap.

  • Derekwaisy (unregistered)
    Comment held for moderation.

Leave a comment on “Demo Most Dear”

Log In or post as a guest

Replying to comment #:

« Return to Article