Now about that change request...
-
Sales: "The customer needs change x done RIGHT NOW!"
Sales: "The customer needs change y done RIGHT NOW!"
Us: "OK, we'll do them concurrently. This means that we CANNOT roll them out separately."2 days later:
Sales: "Deploy ONLY change y. Change x is not approved."Us: "That's not possible. It would invalidate all testing."
Sales: "WAAAAAAAAAAAAAAAAAH"
Sales VP: "THIS IS UNACCEPTABLE"
Our VP: "Do it or you're fired."
Us: "Bad things z, w, and q may happen. They will cost the company $r if it does, and we will bill for the support time."[2 days later]
Operations: "OMFG z, w and q! It's costing us $r!"
Us: "Told you so!"
Our VP: "How could this happen!? We have all these QA processes in place!"
Me: "Well, frankly, the QA processes do a shitty job detecting q"
My boss: "Shutup Weng. Stop speaking truth to power. It's bad for your health."
Our director: "We will correct the problem immediately."
Operations: "$r! Where can we transfer this cost?"
Our VP: "Our cost center is 12345"[2 days later]
Sales: "OMFG WHY DID YOU y? ONLY x WAS APPROVED!"[End of month]
Sales: "OMFG YOU CAN'T BILL US FOR SUPPORT UNLESS WE CAN PASS THAT ON TO THE CLIENT! IT WOULD CUT INTO OUR SPECTACULAR DIVISION PROFITS!"
Our VP: {silently cancels the billing ticket for the support, and the tickets for changes x and y}[Epilogue]
2 months later change y is still 'up the spout' ready to go, and another change request comes in. When presented with the decision to bundle it or roll it back, the client decides they never really wanted it anyway[Double-epilogue]
Owing to poor financial performance (i.e. we didn't bill enough), we let go 2 developers.
-
This is a WTF worthy of the front page (pity how it would be mangled), but why did you drop it in this particular thread?
-
@boomzilla, @pjh i'd like to petition splitting this post into a separate sidebar toipic so that we can give it proper appreciation for the spectacular WTF that it is.we just can't do it justice sitting here in this thread.Thanks @PJH!
-
Done. Not sure about the title, but I'm sure @Weng or someone can change it if a more suitable one comes to mind.
-
-
Yes? you had a point to make?
-
I was going with:
Do this unapproved thing! Why did you do that?
But then it was giving me errors. That's when I noticed that you beat me to it.
-
No. Needing to have a point is a barrier to post count and all that.
-
-
What's funny is that @PJH gets the "Nice Topic" badge because technically he created the topic.
-
@boomzilla says @PJH Is Doing It Wrong™
-
-
I thought we had a new bot feature here, but nope, @boomzilla c heated.
-
@boomzilla says @PJH Is Doing It Wrong™
hmm.... i keep meaning to make that change to @sockbot so that we can have you do that without TL4+ having to edit your posts to do that.
-
Yes master Commander @Accalia Shepard, I shall appear as summoned.
-
No I don't, because I didn't...
-
-
I hope those two developers sent their sincere thanks to the sales team for being kicked out.
-
It seemed vaguely related and I didn't really know how far I was going with it until I was done. And by then I was late for work and just posted the damn thing.
Also I'm fairly certain I've posted a variation on this before
-
-
@PJH Jeffed it
i'mma have to ask you to explain that one, because you've got to be usinf a difinition of Jeff that i'm unfamiliar with.
-
Sales actions are understandable. They don't get paid for IT activities. They are paid on a per unit shipped basis. Therefore it is, naively, in their interest to con us out of getting paid for our work and dispute all charges.
The real problem is our management, who always cave when disputes arise,combined with an atrocious financial arrangement.
Note our transfer cost is often lower than the cost of the developer doing the work, and that beyond a certain staffing level (which is insufficient even for day to day operational support) we need to recover our pay from other departments.
-
Also I'm fairly certain I've posted a variation on this before
It sounded familiar. But still fun (for us).
-
i'mma have to ask you to explain that one
It's in the Discopaedia
To move posts around unnecessary. Putting them in a new topic for your own convenience.
Example: I jeffed these posts to a new topic because they obstructed my view
-
.... by that definition it was i who Jeffed the posts through @PJH as i was the one that requested the topic change so we could marvel at the splendor of @weng's WTF in a better manner.
-
The real problem is our management, who always cave when disputes arise,combined with an atrocious financial arrangement.
Firing the people that make the thing that the sales team sells because they don't make as much as the sales team is the kind of reasoning you need to be management to understand.
-
May I draw your attention to a rather important word there...
> To move posts around unnecessarily.
And someone ought to take care of that spellar.
-
Sales: "Deploy ONLY change y. Change x is not approved."
Sales: "OMFG WHY DID YOU y? ONLY x WAS APPROVED!"
Anyone else notice this? MAKE UP YOUR MIND, SALES! Nobody likes you!
-
This is why everyone keeps records of what was requested to be deployed. The contradiction in that kind of thing is really really common when dealing with certain kinds of individuals.
-
What is necessary, really? When you get right down to it, I mean
Would it be necessary to enforce different threads if everyone suddenly started talking exclusively in /t/1000?
-
Sales actions are understandable... it is, naively, in their interest to con us out of getting paid for our work...
I'm presuming that it's not in their longterm interests to run the dev team into the ground. They need to recognize in their dark little hearts that all they sell is empty promises without someone around to actually make their features real.
(It sounds like the real WTF is the institutional setup of the company...)
-
In defense of sales, given their clients, they apparently don't even need developers:
@Weng said:[Epilogue]2 months later change y is still 'up the spout' ready to go, and another change request comes in. When presented with the decision to bundle it or roll it back, the client decides they never really wanted it anyway
So if sales charged them for y, and they didn't want it after all, what are the developers bringing to the table? They should fire all the developers and have sales just keep selling nothings.
-
fire all the developers
You can only sell nothing so many times though, can't you? Or is this another case of the "fuck, let me throw money at you for no conceivable benefit to myself" mentality again?
-
What is necessary, really?
Pretending this is serious for the moment...
Typically, someone asked for the move, instead of a moderator type proactively curating the topics. Though seriously, @Weng's post was pretty epic, and deserved the attention that a new topic gets.
-
Sales doesn't sell IT solutions. They sell widgets. Manufacturing makes widgets. All IT does is enabled the orders to get from the customers arbitrary data feed to manufacturing.
Traditionally, there were tiny IT teams embedded with each manufacturing plant each doing things a bit differently. They were paid for by the manufacturing plant that owned them.
Then my team arose from that he'll and started working for ALL plants. This gets sales a lot of whizzy stuff they didn't have before (like being able to sell widgets made at many plants instead of just individuals). But their opinion is that they should just get paid for the widgets per normal. Manufacturing plants don't want to pay us because we are not beholden to them. The work they pay for might get pulled and sent to another plant later!
-
Is it just me or doesn't this happen almost every day as a developer? When do users ever know what they want or understand what their asking for? The TRWTF is not using branching or some type of source control to accomplish what they wanted. Developer x feature in branch 1, develop y feature in branch 2. Deploy branch 1. (cust/sales/boss is happy) Merge branch 2 into 1 when completed then deploy or in your case delete branch 2. Basic code management 101... I dont know your code base though was there a specific reason not to do this?
-
From my understanding, it sounded like they didn't have time/manpower to deliver the two features seperately...
-
Technical and logistical constraints. Branching can be done, but merging can't.
And the two changes often require cumulative changes to the config of external systems that we have no access or control of
-
If 2 changes affect the same code, you can't really do them in parallel because of merging issues. Doing them separately also means testing the same area twice.
-
Actually, doing them individually requires 3 test passes. One for each individually and one integrated. We have trouble getting buy in from the other involved parties for one round.
-
@PJH is the creator of the topic, but @Weng is the creator of the first post, which is who the badge is awarded to. Nothing changed.
-
Pretending this is serious for the moment..
I just wanted an excuse to use something from the discopaedia since I'd been perusing it. AFAIK, neither you nor @pjh have actually jeffed any posts, everything I've seen was at someone's request. Not to sound like a brown nose, but you're doing a good job guys
-
AFAIK, neither you nor @pjh have actually jeffed any posts
I can fix that right quick.
-
I can fix that right quick.
Consider starting with
/t/6979
if you have a few hours to spare...
-
Come on now, don't be mean.
-
Give me a mars bar and a two litre of Mr. Pibb and I'll do it.
-
And trust level 4, that's kind of a prerequisite.
-
Oh. Right.
Well then. I guess that's not going to happen.
And that would have been such a good cure for my insomnia too
-
-
Huh.. So that is a thing?
Interesting.