Is this really SOP?



  • I'm fairly new to this industry (as a professional), so maybe I'm missing something...

    We act as an intermediary between our customers, and use a third-party order matching engine. We have an API that exposes some of the guts of our application for customers. One of the things it does is act as a proxy to submit transactions to the third-party processing system. The flow is sort of like this:

    • Customer 1 submits an order to us
    • We forward order to matching engine
    • Customer 2 submits an order directly to matching engine
    • Matching engine matches orders on several criteria and sends a "matched" message to all parties
    • Repeat for n orders from m customers
    The customer decides that they don't want to have to submit each transaction individually, but instead would like to do something like:
          Vector transIds = createTransaction(vectorOfRecordsToUseToCreateTransactions);

    This sounds well and good, but the third party processing system batches their transactions, and their matching algorithm does not necessarily match things in the order of submission (thoroughly documented). Accordingly, if you submit transactions one at a time, everything works as expected. If you submit a bunch of them at the same time, the order of matching is (by spec) not what you actually want.

    As such, we documented this and created some test cases to verify it. Naturally, I expected the feature to be scrapped, as no customer would ever use it because it couldn't give the desired results.

    However, the powers that be decided that we should spend the time to code, document and test this (rather large invasive) feature, and formally release it to our clients. Naturally, the developers at the clients called up saying WTF? and nobody used it.

    I know the Dilbertian stereotypical PHB, but why would a real life development manager, short on staff and overloaded on work, waste an entire release cycle for something that could not possibly ever be used?



  • @new at this said:

    I know the Dilbertian stereotypical PHB, but why would a real life development manager, short on staff and overloaded on work, waste an entire release cycle for something that could not possibly ever be used?

    Managers are not normally judged based on customer satisfaction. That pretty much covers it. 



  • @new at this said:

    This sounds well and good, but the third party processing system batches their transactions, and their matching algorithm does not necessarily match things in the order of submission (thoroughly documented). Accordingly, if you submit transactions one at a time, everything works as expected. If you submit a bunch of them at the same time, the order of matching is (by spec) not what you actually want.
    Hmm. Wouldn't it be prudent to specify (and, of course, implement) the function to return the transaction IDs in the order of the list of records passed to it? (Or is it impossible to programmatically map the returned transaction IDs to the records they were generated for?)

    I know the Dilbertian stereotypical PHB, but why would a real life development manager, short on staff and overloaded on work, waste an entire release cycle for something that could not possibly ever be used?
    It may be that you have to go through all that trouble just because somebody, months or years ago, carelessly specified that your product API includes that function, and now it absolutely must be implemented or somebody else will take the lack of that function as a pretext to bill your company for failing to comply with their original contract... or something like that. (I wish that really was as absurd as it sounds.)

    Or maybe it's as simple as this: Customer wants it; customer will pay for it; therefore, you implement it. It might not make any technical sense, but it certainly makes business sense to comply with a paying customer's wishes.



  • @new at this said:

    I know the Dilbertian stereotypical PHB, but why would a real life development manager, short on staff and overloaded on work, waste an entire release cycle for something that could not possibly ever be used?

     I find that there's generally a sense of "we said we're going to do it, so now we have to do it" mentality.  If we sit here debating whether or not we should do it, we'd be losing time that could be spent working on it......

    It's also possible that when you said it wouldn't work, the PHB dismissed it as you trying to weasel out of work.

    Not knowing your system though, here's a thought.  The customer wants to submit things to you in a batch, which you will then turn around and send to third party.  And the third party's the problem.  Any reason you can't split up what the customer sent you and send them individually?  Customer probably wont even notice.

    Rest assured though.  If you do implement the feature with its brokenness, you will get a bug report from the customer (even if you talked to them about it before), and a boss pointing the finger at you (eve n though you talked to him about it before).



  • @vt_mruhlin said:

    Rest assured though.  If you do implement the feature with its brokenness, you will get a bug report from the customer (even if you talked to them about it before), and a boss pointing the finger at you (eve n though you talked to him about it before).

    Which is exactly why you recorded a bug early in the process indicating that it wouldn't work for various reasons, right? 



  • @un.sined said:

    @vt_mruhlin said:

    Rest assured though.  If you do implement the feature with its brokenness, you will get a bug report from the customer (even if you talked to them about it before), and a boss pointing the finger at you (eve n though you talked to him about it before).

    Which is exactly why you recorded a bug early in the process indicating that it wouldn't work for various reasons, right? 

     

    No, because the PHB will look at his spreadsheet and see that there's a bug against my feature that hasn't been fixed in several months, so he'll tell me that I absolutely have to fix that bug right now.  I'll tell him that I can't fix it because the whole project is bullshit.  Then he'll either tell me to "just take care of it", or "you have to go talk to Product Level Management about that."  PLM will never respond to my emails and will be "really busy" whenever I go to their cubes.  Two weeks later, PHB will run the spreadsheet again.....

     


Log in to reply