OBTW



  • My boss has my peer working on some web service that was to be used by another team. The guy on the other team apparently knows only COBOL, and doesn't quite get the concepts of web service, web server, XML, jar file, Java, object encapsulation and copying files.

    For about three months, my peer has been holding this guys' hand and (painfully) walking him through every step. It doesn't help that this other guy likes to go for four hour walks in the middle of the day.

    Finally, my boss gave my peer a directive: get it done this (past) Friday as it has to be tested for release in two weeks. I tell my peer to go stand over the guy and lean on him to get his part done. He does.

    This morning, my boss sends my peer an email:

    Dear Schmuck: Blah. Blah. Blah. OBTW, the business users just decided that they want to be able to integrate this web service function with a totally separate application suite that has somewhat different needs. They have directed the other developers to start using your service, so make sure it will work with those other applications too.

    Um, capacity planning, anyone? Maybe test the code from the other team to make sure that it's properly meshed with our WSDL, etc?

    Upon calling the other team, we discover that they will be calling this in response to user input from our customers using data entry system X. It turns out the volume from X will absolutely overwhelm our server which was sized for the much more modest needs of the original target audience. 

    We send an email announcing the disconnect. The users demand that we support it anyway. I told them that rather than hold off while waiting on budget, approvals, orders, installations and setups to get new hardware, we do have another option - IF they are willing to be a bit flexible.

    I recently finished a project that would free up about 90% of the capacity we previously used on our servers. While those newly available resources are targeted to support another project four months out, we could temporarily lend them to this project until the new hardware could be purchased.

    <insert massive turf war here>

    At this point, I drag my boss out of harms' way and we watch the sparks fly from the gallery. User A now has a solution. User B won't temporarily  give up the resources allocated to her even though she won't need them for months.

    I interject that if the requirements had been known UP FRONT, that the server that was purchased for this project would have been of the appropriate size and this whole mess could have been avoided.

    At this point, the three of us walk over to my boss' boss' office and explain it all. She has a workable - if required-only-due-to-stupid-user-failing-to-plan-ahead solution - now she can deal with the politics.

    I love Mondays.



  • So what's the argument the users are presenting?  They fucked up. They didn't plan or notify anybody. Why should anybody other than then have to pay for it?



  • @C-Octothorpe said:

    So what's the argument the users are presenting?  They fucked up. They didn't plan or notify anybody. Why should anybody other than then have to pay for it?

     

    God that sounds like the statement of a newbie.  But you're not a newbie.  I have no idea how you can say that without sarcasm tags.

    In Utopia, you're absolutely right.  In the real world, the end users don't give a damn whether it was their poor planning or not (or, quite frankly, probably don't even see it as their poor planning).  It must be done according to Their Word.

     



  • @snoofle said:

    It doesn't help that this other guy likes to go for four hour walks in the middle of the day.
     

     Wha... have you concidered getting him an alzheimer's nurse?



  • I dont know if I should congrats you or not for being able to turn an issue that the users could not see anything wrong with into a different issue (turf warfare) which they do recognize as an issue.



  • @Anketam said:

    I dont know if I should congrats you or not for being able to turn an issue that the users could not see anything wrong with into a different issue (turf warfare) which they do recognize as an issue.

    Don't congratulate me - it was purely unintentional; a side benefit if you will.

    I honestly figured that since our request-approve-purchase-install cycle is 2.5 months, that there'd be enough wiggle room - if everyone cooperated and everything was expedited - to get it done and free the resources without impacting the work four months down the line.

    Silly me.

     



  • @nonpartisan said:

    @C-Octothorpe said:

    So what's the argument the users are presenting?  They fucked up. They didn't plan or notify anybody. Why should anybody other than then have to pay for it?

     

    God that sounds like the statement of a newbie.  But you're not a newbie.  I have no idea how you can say that without sarcasm tags.

    In Utopia, you're absolutely right.  In the real world, the end users don't give a damn whether it was their poor planning or not (or, quite frankly, probably don't even see it as their poor planning).  It must be done according to Their Word.

     

    Supporting story: I write software for some of the control systems in a nuclear power plant. The hardware for my team's particular system is stored in many large cabinets which all stand side by side in some side room of the plant. These cabinets receive power from a bunch of 240V boxes that hang from the ceiling and plug into the tops of the cabinets. Unfortunately, the company who is actually constructing the plant didn't make the room the appropriate dimensions when they built it, so there's no room for the power boxes. Even though they've had the design specs for our system for years.

    Did they fix it? Nope, they came to use and told us we needed to redesign our cabinets to fit in a smaller area, maybe move the boxes somewhere else. Which would work except that our design has already been approved and certified by the NRC, etc. Not to mention revising drawings for cable length (yes, the lengths of every single cable are documented and must be kept up-to-date), physical layout, then re-ordering parts and cabinets...

    In the end, we told them it'd cost a million dollars. They finally backed off and are working on a solution themselves.



  • @snoofle said:

    @Anketam said:

    I dont know if I should congrats you or not for being able to turn an issue that the users could not see anything wrong with into a different issue (turf warfare) which they do recognize as an issue.

    Don't congratulate me - it was purely unintentional; a side benefit if you will.

    I honestly figured that since our request-approve-purchase-install cycle is 2.5 months, that there'd be enough wiggle room - if everyone cooperated and everything was expedited - to get it done and free the resources without impacting the work four months down the line.

    Silly me.

     

    Now they're going to argue for 2 months, then agree to what you suggested, order the parts, and then the team that originally had them won't get them on time and will go off on a tirade.


  • @Lorne Kates said:

    @snoofle said:
    It doesn't help that this other guy likes to go for four hour walks in the middle of the day.
    Wha... have you concidered getting him an alzheimer's nurse?

    Find the address of his crackhouse and set up a workstation there. People who go for 4-hour "walks" ain't walking.



  • @snoofle said:

    @Anketam said:
    I dont know if I should congrats you or not for being able to turn an issue that the users could not see anything wrong with into a different issue (turf warfare) which they do recognize as an issue.

    Don't congratulate me - it was purely unintentional; a side benefit if you will.

    I honestly figured that since our request-approve-purchase-install cycle is 2.5 months, that there'd be enough wiggle room - if everyone cooperated and everything was expedited - to get it done and free the resources without impacting the work four months down the line.

    Silly me.

    In that case I wont.  Still I learned a valuable lesson.  If the client/customer does not understand the issue, convert it to a new issue that will cause the necessary hell to be raised.



  • @nonpartisan said:

    @C-Octothorpe said:

    So what's the argument the users are presenting?  They fucked up. They didn't plan or notify anybody. Why should anybody other than then have to pay for it?

     

    God that sounds like the statement of a newbie.  But you're not a newbie.  I have no idea how you can say that without sarcasm tags.

    In Utopia, you're absolutely right.  In the real world, the end users don't give a damn whether it was their poor planning or not (or, quite frankly, probably don't even see it as their poor planning).  It must be done according to Their Word.

    You're right, it does sound like that. I, however, have found that stripping away all the extraneous details/noise of the situation and cornering the person(s) with the root cause (them) forces them to concede the argument.  "Did you, or did you not tell us about X?"

    I'm not saying that this happens very often or is the rule, but it does happen. I suppose I have been fortunate to work with (mostly) reasonable people, both on the technical and business side of things.



  • @snoofle said:

    At this point, I drag my boss out of harms' way and we watch the sparks fly from the gallery. User A now has a solution. User B won't temporarily  give up the resources allocated to her even though she won't need them for months.
    Having worked for large corporations for long enough, I would be siding with User B. There is a very good chance, that User B won't get the resources back when she needs them.



  • @snoofle said:

    <pragmatic solution>




  •  If the client/customer does not understand the issue, convert it to a new issue that will cause the necessary hell to be raised.

     

    That's an appropriate use of "The Decorator" Pattern.



  • @snoofle said:

    The guy on the other team apparently knows only COBOL, and doesn't quite get the concepts of web service, web server, XML, jar file, Java, object encapsulation and copying files.
     

    That (anti)-climax right there alone made thread worth reading.  applauds



  • @Anketam said:

    @snoofle said:

    @Anketam said:
    I dont know if I should congrats you or not for being able to turn an issue that the users could not see anything wrong with into a different issue (turf warfare) which they do recognize as an issue.

    Don't congratulate me - it was purely unintentional; a side benefit if you will.

    I honestly figured that since our request-approve-purchase-install cycle is 2.5 months, that there'd be enough wiggle room - if everyone cooperated and everything was expedited - to get it done and free the resources without impacting the work four months down the line.

    Silly me.

    In that case I wont.  Still I learned a valuable lesson.  If the client/customer does not understand the issue, convert it to a new issue that will cause the necessary hell to be raised.

     

    Bonus notches if, as in this case, you go from a real issue they reject to an imaginary one they accept.

     



  • @Rick said:

    @snoofle said:

    At this point, I drag my boss out of harms' way and we watch the sparks fly from the gallery. User A now has a solution. User B won't temporarily  give up the resources allocated to her even though she won't need them for months.
    Having worked for large corporations for long enough, I would be siding with User B. There is a very good chance, that User B won't get the resources back when she needs them.

    That's a funny way to spell, "It's virtually guaranteed".  At least, the users I have who don't think to ask for these things until a week before what they think is "go live" tend to be exceedingly poor at following through with requesting the additional servers - especially if they're not the ones who suffer for them not coming in.

    Also, our management won't fire them for not ordering the additional servers on time, even if it caused major delays for an equally or more important project.

    That having been said, I'd typically opt for the turf war.  They're fun to watch, and I find it much easier to defeat User A's whims with the able assistance of User B in a battle that User A recognizes, than it is to defeat User A's whims on my own against an issue User A doesn't recognize.  If User B is well chosen, I may not even have to participate.

    But I enjoyed redirecting two users who didn't understand the issue with their requests to a turf war that neither fully understood.  Unfortunately, one of those users survived that.  Still, we had several years of not having to deal with said user as a result of that.



  • @Anketam said:

    Still I learned a valuable lesson.  If the client/customer does not understand the issue, convert it to a new issue that will cause the necessary hell to be raised.
     

    Isn't that how everybody does it?

    I always convert my problems to simple manhour/money/delays costs when talking to non-technical management (especially if it's of the C*O kind). 

    "We'd need to hire X more developers / QA guys / whatever, add Y dollars to the budget and/or delay completion by Z months"  is actually usefull for them, while "We'd need to refactor this and rewrite that" isn't.

     



  • @Anketam said:

    In that case I wont.  Still I learned a valuable lesson.  If the client/customer does not understand the issue, use it to highlight another already-existing issue.

    FTFY. It looks like the underlying issue is one of silo mentality, and inter-departmental teamwork would have helped them overcome this issue.

    @Rick said:

    Having worked for large corporations for long enough, I would
    be siding with User B. There is a very good chance, that User B won't
    get the resources back when she needs them.

    This is supposition, not fact; there's a very good change that user B won't get the resources back if she does not stipulate conditions for lending them out.

    It appears she's making the assumption that she won't get them back if they're lent out, so she's refusing to lend them.

    What is fact is that the whole organisation stands to lose out as a result of her stubbornness - there are resources sitting around that could benefit someone and she's selfishly hogging them based upon supposition and opinion.

    @bdew said:

    I always convert my problems to simple
    manhour/money/delays costs when talking to non-technical management
    (especially if it's of the C*O kind).

    That, squared.

    Speak the language of the business when speaking to business, and business then understands enough to make an informed decision. Baffle them with techy bullshit and they're none the wiser, and techies get frustrated that they're not being understood. Sometimes the problem isn't who's listening, it's who's talking.



  • @Cassidy said:

    This is supposition, not fact; there's a very good change that user B won't get the resources back if she does not stipulate conditions for lending them out.

    It appears she's making the assumption that she won't get them back if they're lent out, so she's refusing to lend them.

    What is fact is that the whole organisation stands to lose out as a result of her stubbornness - there are resources sitting around that could benefit someone and she's selfishly hogging them based upon supposition and opinion.

    Look at it the other way. If people bend over backwards to help the team that didn't do proper planning, that didn't communicate their requirements, and that waited until the last possible minute to clarify things-- what incentive is there for them to improve in the future? "Well, last time we fucked up royally, someone swept in and made it work, so let's just make fuck up royally our standard operating procedure."

    If someone screws up they need to suffer for it otherwise there is no learning. For that reason alone, I'm with user B here.



  • But Cassidy, that was not what I learned you can't FTFY what is in my head!  Anyways...

    @Cassidy said:

    This is supposition, not fact; there's a very good change that user B won't get the resources back if she does not stipulate conditions for lending them out.

    It appears she's making the assumption that she won't get them back if they're lent out, so she's refusing to lend them.

    What is fact is that the whole organisation stands to lose out as a result of her stubbornness - there are resources sitting around that could benefit someone and she's selfishly hogging them based upon supposition and opinion.

    It is not a supposition, it is a risk.  A risk with a high probability of happening, and with a high level of impact.  There are ways to mitigate it like making [false] promises to return it before they need it.

     



  • @blakeyrat said:

    @Cassidy said:

    This is supposition, not fact; there's a very good change that user B won't get the resources back if she does not stipulate conditions for lending them out.

    It appears she's making the assumption that she won't get them back if they're lent out, so she's refusing to lend them.

    What is fact is that the whole organisation stands to lose out as a result of her stubbornness - there are resources sitting around that could benefit someone and she's selfishly hogging them based upon supposition and opinion.

    Look at it the other way. If people bend over backwards to help the team that didn't do proper planning, that didn't communicate their requirements, and that waited until the last possible minute to clarify things-- what incentive is there for them to improve in the future? "Well, last time we fucked up royally, someone swept in and made it work, so let's just make fuck up royally our standard operating procedure."

    If someone screws up they need to suffer for it otherwise there is no learning. For that reason alone, I'm with user B here.

    In this case it's the customer that didn't plan ahead, not the team.


  • @blakeyrat said:

    @Cassidy said:

    This is supposition, not fact; there's a very good change that user B won't get the resources back if she does not stipulate conditions for lending them out.

    It appears she's making the assumption that she won't get them back if they're lent out, so she's refusing to lend them.

    What is fact is that the whole organisation stands to lose out as a result of her stubbornness - there are resources sitting around that could benefit someone and she's selfishly hogging them based upon supposition and opinion.

    Look at it the other way. If people bend over backwards to help the team that didn't do proper planning, that didn't communicate their requirements, and that waited until the last possible minute to clarify things-- what incentive is there for them to improve in the future? "Well, last time we fucked up royally, someone swept in and made it work, so let's just make fuck up royally our standard operating procedure."

    If someone screws up they need to suffer for it otherwise there is no learning. For that reason alone, I'm with user B here.

    The problem here is that you assume the users have the ability to respond to outside stimulus, adapt to a changing environment while being able to retain, retrieve and apply this knowledge for future use.  I think that's a bit of a stretch, don't you?



  • @blakeyrat said:

    "Well, last time we fucked up royally, someone swept in and made it work, so let's just make fuck up royally our standard operating procedure."

    If someone screws up they need to suffer for it otherwise there is no learning. For that reason alone, I'm with user B here.

    Not going to disagree with that, you make the bed that you lie in after all, but the flipside is when user B fucks up and pleads for help, user A has little incentive to lend a hand (but can smugly remind them of past experiences).

    Look, there's no getting away from the fact that A is at fault, and B has no real reason to step in and help at all. I just find the fact that B gets confrontational over it isn't helping the bigger picture at all, and not going to do her any favours. It's not just A that's suffering, it's the entire organisation, and B has resources that can assist the current situation but continues to hog them through fear of not having them returned.

    In this situation, I've got to question why that fear is the norm, and why the culture is that way.

    @Anketam said:

    It is not a supposition, it is a risk.  A risk with a high probability of happening, and with a high level of impact.  There are ways to mitigate it like making [false] promises to return it before they need it.

    Well, do we know that there is a high probability of it happenning? Or are you talking about your situation/experiences?

    Also, mitigating against it through false promises isn't mitigating risk, it's passing the risk.

    @Sutherlands said:

    In this case it's the customer that didn't plan ahead, not the team.

    And if the organisation is able to take the customer's failure for forward planning, absorb it and deliver, it's likely they'll be viewed more favourably for the next contract. I'm not in the "customer's always right" mode here, I'm coming from the direction that user B has unallocated resources that could be used NOW but are sitting around gathering dust until there comes a time when she needs them.

    Perhaps I'm just used to organisations that work in this non-confrontational style and synergise teamwork to a greater benefit. I dunno how it is Merkin-side.



  • @Cassidy said:

    Perhaps I'm just used to organisations that work in this non-confrontational style and synergise teamwork to a greater benefit.

    Did you just use "synergize" non-ironically?

    @Cassidy said:

    I dunno how it is Merkin-side.

    ... what?

    What the FUCK is going on with this site.



  • @blakeyrat said:

    What the FUCK is going on with this site.


    Archer: Lana

    Archer: LANA

    Archer: LANAAAAAAAAAAA!?

    Lana: What?!

    Archer: Dangerzone



  • @swayde said:

    @blakeyrat said:
    What the FUCK is going on with this site.


    Archer: Lana

    Archer: LANA

    Archer: LANAAAAAAAAAAA!?

    Lana: What?!

    Archer: Dangerzone

    Finally something I can get behind!



  • @Cassidy said:

    @Sutherlands said:

    In this case it's the customer that didn't plan ahead, not the team.

    And if the organisation is able to take the customer's failure for forward planning, absorb it and deliver, it's likely they'll be viewed more favourably for the next contract. I'm not in the "customer's always right" mode here, I'm coming from the direction that user B has unallocated resources that could be used NOW but are sitting around gathering dust until there comes a time when she needs them.

    Perhaps I'm just used to organisations that work in this non-confrontational style and synergise teamwork to a greater benefit. I dunno how it is Merkin-side.

    Going back and looking at what I was responding to... what's your point with quoting me?


  • @Sutherlands said:

    Going back and looking at what I was responding to... what's your point with quoting me?

    Aha - my point wasn't supposed to be a response to yours, more a highlight that the organisation seems to be more focussed upon infighting than realising they could collectively provide a solution to the customer's problem (of their doing).

    Sorry, it was more of a "take that point and run with it" post. I synuhgized!



  • @snoofle said:

    recently finished a project that would free up about 90% of the capacity we previously used on our servers. While those newly available resources are targeted to support another project four months out, we could temporarily lend them to this project until the new hardware could be purchased.

    Thinking about this a bit further...

    *Who* is buying the new hardware?  If it's your group, you missed the opportunity to proceed by *that* much.

    Instead of offering the freed space temporarily to User A, you offer User B the shiny new hardware, which will have more capacity than the 90% you cleared on the old hardware.  (Then make sure that the new hardware has enough more capacity than the old hardware that they'll notice.)

    If it's the business users that didn't tell you about a major project requirement for months, then tell them they need to live with the purchase process - they need resources that aren't available, so they must buy more.  The mentality that they don't need to tell you about requirements until a week or two before go-live is frequently coupled with the attitude of "it works, we're done."  As soon as they go live on the borrowed resource, they'll cancel any requisition for new hardware they may accidentally start in response to your pestering.

    If it's the other team, evade.  The other team won't buy the new hardware in a timely fashion, so you'd erode User B's confidence in you if you managed to convince User B to go down that path.

    Clarification: I assume in any of the three cases I offered above, User A is paying for the new hardware.  Whether they are made to realize it or not is up to your team and your companies processes.


Log in to reply
 

Looks like your connection to What the Daily WTF? was lost, please wait while we try to reconnect.