Do it my way or leave it
-
@TDWTF123 said:
What programme do you reckon is being used to update the product descriptions and pricing data daily? Since it's clearly somewhere Excel exists, the probability it's Excel approaches unity.
WTF?
@TDWTF123 said:
@boomzilla said:
Sadly, since the Excel inanity didn't get implemented, we'll never get the story about the chaos that reigned when the PHB who would have been responsible for emailing the spreadsheets went on vacation.
Still with that nonsense? I thought we'd dealt with it already. That can all be easily automated.Bullshit. With a manager as stupid as described by the OP, there's no way that will work, because she doesn't understand it. Yes, in the fantasy world you and Ronald dreamed up, Excel could be a reasonable solution. And maybe someday blakeyrat will make his peace with git.
-
@Weng said:
Spot on, I'm afraid: it's not about the arguments right, it's about getting right, the root of many a WTF.@Ragnax said:
In other words; the root of the problem is the usual incompetence on the business side, not the IT side. (However; woe on the poor developer that points out that elephant in the room…)
I've made a career out of shooting that particular elephant. You just have to do it with sufficient gusto, complete conviction and have an ally in middle and upper management run interference. And it's very important you have your facts straight, because being wrong is fatal.The average developer would get his/her teeth kicked in because the whole process is too confrontational and the personality types just don't work.
-
@boomzilla said:
@TDWTF123 said:
What didn't you understand? If Excel exists, it's practically certain it's the programme in use for that. We know Excel exists (in that workplace). Ergo, Excel is almost certainly being used. Unless you're talking about Snoofle's ex-employer or some such, data doesn't exist in isolation. People touch it.What programme do you reckon is being used to update the product descriptions and pricing data daily? Since it's clearly somewhere Excel exists, the probability it's Excel approaches unity.
WTF?
@boomzilla said:
Bullshit. With a manager as stupid as described by the OP, there's no way that will work, because she doesn't understand it.
That's some nice circular reasoning there. The manager is an idiot because the Excel solution she proposed can't work, and it can't work because she's an idiot.Except that actually she apparently wasn't an idiot at all, and got things mostly right; her Excel idea needed a little expert tweaking, but was, from what we've heard, fundamentally sound.
-
@TDWTF123 said:
@boomzilla said:
@TDWTF123 said:
What programme do you reckon is being used to update the product descriptions and pricing data daily? Since it's clearly somewhere Excel exists, the probability it's Excel approaches unity.
WTF?
What didn't you understand? If Excel exists, it's practically certain it's the programme in use for that. We know Excel exists (in that workplace). Ergo, Excel is almost certainly being used.Which shoulder alien told you that? Because he obviously didn't read the post where the OP said this:
@ronin said:
We're talking about hundreds of product descriptions from two different CMS, and ten thousands of pricing data records coming from a mainframe that need to be delivered on a daily basis. I don't see how Excel is supposed to serve as a clean solution here.
@TDWTF123 said:
Except that actually she apparently wasn't an idiot at all, and got things mostly right; her Excel idea needed a little expert tweaking, but was, from what we've heard, fundamentally sound.
Heh. OK, I admit it, you had me until this line. Nice troll.
-
@boomzilla said:
@TDWTF123 said:
@boomzilla said:
@TDWTF123 said:
What programme do you reckon is being used to update the product descriptions and pricing data daily? Since it's clearly somewhere Excel exists, the probability it's Excel approaches unity.
WTF?
What didn't you understand? If Excel exists, it's practically certain it's the programme in use for that. We know Excel exists (in that workplace). Ergo, Excel is almost certainly being used.Which shoulder alien told you that? Because he obviously didn't read the post where the OP said this:
@ronin said:
We're talking about hundreds of product descriptions from two different CMS, and ten thousands of pricing data records coming from a mainframe that need to be delivered on a daily basis. I don't see how Excel is supposed to serve as a clean solution here.
Apart from your ignorant and incorrect assistance that Excel can't do those things, I see no contradiction. Excel is well-capable of doing those things. It's almost certainly already being used as part of the workflow, and that's why the manager suggested an Excel-based solution.
Since you still didn't answer the question, what programme do you think is being used to update the 'daily updated' data? Do you think it magically appears in the 'two different CMS' by itself?@boomzilla said:
@TDWTF123 said:
That doesn't even make sense. The argument all the way through has been that Excel is a perfectly reasonable way to do things. Do you just trot out the troll line every time you lose another point?Except that actually she apparently wasn't an idiot at all, and got things mostly right; her Excel idea needed a little expert tweaking, but was, from what we've heard, fundamentally sound.
Heh. OK, I admit it, you had me until this line. Nice troll.
The fact remains that Excel is far, far more capable than you're giving it credit for. In fact, Supercalc was more capable a third of a century ago than you give Excel credit for.
-
@TDWTF123 said:
@boomzilla said:
With a manager as stupid as described by the OP, there's no way that will work, because she doesn't understand it.
That's some nice circular reasoning there. The manager is an idiot because the Excel solution she proposed can't work, and it can't work because she's an idiot.Oops, forgot to mock you for this. What thread did you read? She wouldn't understand the automation and so would veto its implementation. So it wouldn't work because she wouldn't allow it to work.
You and Ronald made a case that it's possible for Excel to be a reasonable solution to a similar problem, and that's fine, but it simply doesn't apply to the OP's situation. So either you're not being clear about that, being stupid or trolling. I'm being generous and assuming the last option.
-
@TDWTF123 said:
Apart from your ignorant and incorrect assistance that Excel can't do those things, I see no contradiction. Excel is well-capable of doing those things. It's almost certainly already being used as part of the workflow, and that's why the manager suggested an Excel-based solution.
So...they have a mainframe and two CMS' worth of data, and you think that instead of using those applications, they're using Excel. It's vaguely possible this is happening, but unlikely. Your claim about "almost certainly" is 100% wrong. There's absolutely no certainty that Excel is being used in the workflow to update their systems. YOU MADE THAT UP. We know why the manager imagined an Excel solution. Because that's all she knows. There are many ways she could be using Excel outside of maintaining a list of products and prices.
@TDWTF123 said:
The fact remains that Excel is far, far more capable than you're giving it credit for.
No it isn't. I haven't said anything about what it can or can't do. My comments have been with respect to what I believe the manager would allow.
@TDWTF123 said:
Do you just trot out the troll line every time you lose another point?
No. It's just me giving you the benefit of the doubt that you have better reading comprehension and critical thinking skills than blakeyrat. It's like all you read was that someone proposed Excel, and you ignored the rest of what was going on, both technologically and organizationally.
-
@boomzilla said:
So either you're not being clear about that, being stupid or trolling. I'm being generous and assuming the last option.
It all comes down to the old saying ofNever wrestle with a pig,
The pig will enjoy it and you'll only get dirty
-
-
@OzPeter said:
@boomzilla said:
So either you're not being clear about that, being stupid or trolling. I'm being generous and assuming the last option.
It all comes down to the old saying ofNever wrestle with a pig,
The pig will enjoy it and you'll only get dirtyIt does pass the time, though.
-
@boomzilla said:
It does pass the time, though.
Working on the gopher racer is better use of that time, though.
-
@boomzilla said:
So...they have a mainframe and two CMS' worth of data, and you think that instead of using those applications, they're using Excel. It's vaguely possible this is happening, but unlikely. Your claim about "almost certainly" is 100% wrong. There's absolutely no certainty that Excel is being used in the workflow to update their systems. YOU MADE THAT UP. We know why the manager imagined an Excel solution. Because that's all she knows. There are many ways she could be using Excel outside of maintaining a list of products and prices.
TDWTF123 is saying that the data has to get INTO the CMS somehow. That might be an Excel spreadsheet that imports the data, you can change it and save it. So there could very well be Excel in the workflow. I still don't agree with him, because 1) If it's all stored in a database, I think it's more likely that there is some sort of program or web interface to adjust the data (that's how we do it), and 2) even if it gets updated in Excel, I don't think you would want Excel to update the DB AND send the data to the partner, although it's possible that's the best way to do it.
-
@Sutherlands said:
TDWTF123 is saying that the data has to get INTO the CMS somehow.
@Sutherlands said:it's more likely that there is some sort of program or web interface to adjust the data
...But that's... The definition... Of a CMS...
-
@TDWTF123 said:
Still with that nonsense? I thought we'd dealt with it already. That can all be easily automated.
An explicitly manual task? Remember that the documentation explicitly called for regular merging and maintenance. That doesn't sound like an automated process nor like one designed to be easily automated.
No one denies that Excel can be used as a powerful data warehouse frontend/GUI toolkit. It's just that in this case it doesn't seem like those features would be used.
Also, going through Excel as described in the opening post might introduce unneccessary complexity, depending on how the company handles data. If all data lives in Excel spreadsheets then yes, doing it in Excel is the obvious solution. If, on the other hand, the data lives in a database and is already used by non-Excel software then using Excel means that you export the data from the database into Excel, merge it with the "official" spreadsheet, transfer that to the other party and do everything backwards when an update comes in. Even if you make Excel do the importing work it would seem obviously easier to just make an API client/server that talks directly to the database.
-
@Sutherlands said:
TDWTF123 is saying that the data has to get INTO the CMS somehow. That might be an Excel spreadsheet that imports the data, you can change it and save it.
Yes, but he has no evidence at all for Excel coming anywhere near this stuff.
@Sutherlands said:
I still don't agree with him, because 1) If it's all stored in a database, I think it's more likely that there is some sort of program or web interface to adjust the data (that's how we do it), and 2) even if it gets updated in Excel, I don't think you would want Excel to update the DB AND send the data to the partner, although it's possible that's the best way to do it.
The OP mentioned 2 CMSes and a mainframe, which (among all the other details) suggest that this isn't a little mom and pop operation. I'd be really surprised if (against all evidence) the canonical data isn't stored in the mainframe or whatever DB it and the CMSes talk to. I wouldn't be surprised to find out that you mainly talk to the mainframe using a terminal emulator, but a web interface wouldn't be too shocking, either. I wouldn't be totally shocked to find out that the occasional import of new stuff happens from Excel, but I'd be really shocked if most of the work was done that way, as opposed to people updating data right in the application. Talk of a mainframe suggests some sort of ERP type of application, which will have all sorts of ways to manipulate things.
-
@joe.edwards said:
@Sutherlands said:
Having pricing data and a description that generates a product page would be the CMS. How you manage the data in there is less important to calling it a CMS, I think.TDWTF123 is saying that the data has to get INTO the CMS somehow.
@Sutherlands said:it's more likely that there is some sort of program or web interface to adjust the data
...But that's... The definition... Of a CMS...
-
@Sutherlands said:
How you manage the data in there is less important to calling it a CMS, I think.
That's the M.
-
@boomzilla said:
@Sutherlands said:
What's the weather like up there in your ivory tower? Down here on the ground, the weather looks a lot like Excel again today.TDWTF123 is saying that the data has to get INTO the CMS somehow. That might be an Excel spreadsheet that imports the data, you can change it and save it.
Yes, but he has no evidence at all for Excel coming anywhere near this stuff.
@Sutherlands said:
I still don't agree with him, because 1) If it's all stored in a database, I think it's more likely that there is some sort of program or web interface to adjust the data (that's how we do it), and 2) even if it gets updated in Excel, I don't think you would want Excel to update the DB AND send the data to the partner, although it's possible that's the best way to do it.
The OP mentioned 2 CMSes and a mainframe, which (among all the other details) suggest that this isn't a little mom and pop operation. I'd be really surprised if (against all evidence) the canonical data isn't stored in the mainframe or whatever DB it and the CMSes talk to. I wouldn't be surprised to find out that you mainly talk to the mainframe using a terminal emulator, but a web interface wouldn't be too shocking, either. I wouldn't be totally shocked to find out that the occasional import of new stuff happens from Excel, but I'd be really shocked if most of the work was done that way, as opposed to people updating data right in the application. Talk of a mainframe suggests some sort of ERP type of application, which will have all sorts of ways to manipulate things.
You clearly haven't stepped down from your tower into the world of real work in a very long time, or you'd realise how daft it is to suggest anyone would update the kind of data we're talking about using a terminal session. They might upload a file with pre-prepared changes via a term sesh, but that file has to be created somehow.
What you still seem to be missing is that Excel will quite happily interface with things like ERP. It is not in the least bit uncommon to find people using Excel as an interface to ERP/CMS/whatnot because Excel is designed to do that these days.
The bad motoring analogy here would be that you're criticising cars on the basis that the horses that pull them need to be stabled somewhere. Yes, your view is that nonsensical.
@boomzilla said:YOU MADE THAT UP.
No, it's easy to see down here at ground level. That it happens to very neatly explain everything about the OP's story suggests that not only am I factually correct, but that the inference I drew from the fact is also correct.
-
Excel only seems great for that kind of work, but that's because you haven't used Lotus Notes. Notes would be the proper solution in the OP's story.
-
@j6cubic said:
@TDWTF123 said:
The criticism of the process implied that it could and should be automated. The way I understood things, the necessity to merge is being created because the process calls for a snapshot to be taken. That snapshot doesn't need to be created, though.Still with that nonsense? I thought we'd dealt with it already. That can all be easily automated.
An explicitly manual task? Remember that the documentation explicitly called for regular merging and maintenance. That doesn't sound like an automated process nor like one designed to be easily automated.
@j6cubic said:If, on the other hand, the data lives in a database and is already used by non-Excel software then using Excel means that you export the data from the database into Excel, merge it with the "official" spreadsheet, transfer that to the other party and do everything backwards when an update comes in. Even if you make Excel do the importing work it would seem obviously easier to just make an API client/server that talks directly to the database.
Thing is, the way Excel works it doesn't do it the way you suggest, and it does do it the way you say would be easier. Which is the point, really: Excel can handle this very nicely, because this is just the kind of thing Excel gets used for the whole time.
Like you say:@j6cubic said:
Excel can be used as a powerful data warehouse frontend/GUI toolkit.
I am entirely baffled as to why you go on to say that those features wouldn't be used, given that what we're talking about is (essentially) updating data and putting it into a database.
-
@TDWTF123 said:
What's the weather like up there in
your ivory towerthe land where people read what is written?FTFY
@TDWTF123 said:
You clearly haven't stepped down from your tower into the world of real work in a very long time, or you'd realise how daft it is to suggest anyone would update the kind of data we're talking about using a terminal session. They might upload a file with pre-prepared changes via a term sesh, but that file has to be created somehow.
No, I've seen this a lot. That's the point of having ERP. You have an application where you can get work done by updating costs and prices and inventory and what not.
@TDWTF123 said:
What you still seem to be missing is that Excel will quite happily interface with things like ERP. It is not in the least bit uncommon to find people using Excel as an interface to ERP/CMS/whatnot because Excel is designed to do that these days.
No. I'm not missing this at all. What you are missing is that OP has said things that imply they do not do this. I'm not sure why you think that I think any of this even after I've explicitly said the opposite. Are you really this proud of your poor reading skills?
@TDWTF123 said:
@boomzilla said:
YOU MADE THAT UP.
No, it's easy to see down here at ground level. That it happens to very neatly explain everything about the OP's story suggests that not only am I factually correct, but that the inference I drew from the fact is also correct.Please quote the part of anything the OP said that implies any of this.
-
@boomzilla said:
@TDWTF123 said:
@boomzilla said:
YOU MADE THAT UP.
No, it's easy to see down here at ground level. That it happens to very neatly explain everything about the OP's story suggests that not only am I factually correct, but that the inference I drew from the fact is also correct.Please quote the part of anything the OP said that implies any of this.
@ronin said:the concept involved a bunch of Excel sheets that would have to be exchanged between us and the other company, and regularly merged and maintained on either side
-
@joe.edwards said:
@boomzilla said:
@TDWTF123 said:
@boomzilla said:
YOU MADE THAT UP.
No, it's easy to see down here at ground level. That it happens to very neatly explain everything about the OP's story suggests that not only am I factually correct, but that the inference I drew from the fact is also correct.Please quote the part of anything the OP said that implies any of this.
@ronin said:the concept involved a bunch of Excel sheets that would have to be exchanged between us and the other company, and regularly merged and maintained on either side
Filed under: Clearly the manager was referring to a live data feed.Yes, I'm sure that it's relatively easy to get data out of the system and into Excel. But that's a loooong way from evidence that they're doing things inside of Excel and pushing it into the system.
-
@boomzilla said:
Yes, I'm sure that it's relatively easy to get data out of the system and into Excel. But that's a loooong way from evidence that they're doing things inside of Excel and pushing it into the system.
I was agreeing with you.
-
@joe.edwards said:
I was agreeing with you.
Oh. Carry on.
-
TDWTF123, I think you imagine the task to be a lot simpler than it is, which is not your fault, considered that I haven't given very much information about its complexity.
Anyway, I don't deny that it would be possible to implement some solution that uses both Excel and the partner's web service (even if it would need a lot of VBA, IMHO taking surely about the same effort as doing it in a real programming language).
But that's not the point at all. The manager didn't say she wanted any implementation as long as it involved Excel. Instead, she wanted exactly the implementation that was specified in her concept. And even if there was a simple, clever and maintainable way to do it in Excel, I highly doubt that it was in her concept, so it would have been equally rejected.
She didn't choose Excel because she had made the informed decision that it was the better solution. She chose it because it was the only IT-ish thing she knew.
My suspicion is that all what mattered to her was to play a vital role in the project so she could take the credit of the its success, even if that meant to do a job that she wasn't qualified for and that wasn't in her responsibility. When the IT project managers created their own concept (which is actually their job) and had it implemented (thereby reducing the importance of her contribution), the project became useless to her, and before she let someone else take any credit, she could as well scrap it altogether. Typical PHB behaviour.
-
@ronin said:
TDWTF123, I think you imagine the task to be a lot simpler than it is, which is not your fault, considered that I haven't given very much information about its complexity.
Anyway, I don't deny that it would be possible to implement some solution that uses both Excel and the partner's web service (even if it would need a lot of VBA, IMHO taking surely about the same effort as doing it in a real programming language).
But that's not the point at all. The manager didn't say she wanted any implementation as long as it involved Excel. Instead, she wanted exactly the implementation that was specified in her concept. And even if there was a simple, clever and maintainable way to do it in Excel, I highly doubt that it was in her concept, so it would have been equally rejected.
She didn't choose Excel because she had made the informed decision that it was the better solution. She chose it because it was the only IT-ish thing she knew.
My suspicion is that all what mattered to her was to play a vital role in the project so she could take the credit of the its success, even if that meant to do a job that she wasn't qualified for and that wasn't in her responsibility. When the IT project managers created their own concept (which is actually their job) and had it implemented (thereby reducing the importance of her contribution), the project became useless to her, and before she let someone else take any credit, she could as well scrap it altogether. Typical PHB behaviour.
Well now you ruined this thread. I was about to go get some popcorn and come back for the show.
-
@ronin said:
And even if there was a simple, clever and maintainable way to do it in Excel, I highly doubt that it was in her concept, so it would have been equally rejected.
Dude! Get out of your ivory tower already! EXCEL CAN DO IT! Also, Excel is already doing it in your company! People who are out there on the ground in the real world know this.
-
@boomzilla said:
@ronin said:
And even if there was a simple, clever and maintainable way to do it in Excel, I highly doubt that it was in her concept, so it would have been equally rejected.
Dude! Get out of your ivory tower already! EXCEL CAN DO IT! Also, Excel is already doing it in your company! People who are out there on the ground in the real world know this.
if the partnering company wanted excel, then who are we to judge?
seriously though, I love the Fabulous Vader.
-
@_leonardo_ said:
if the partnering company wanted excel, then who are we to judge?
Another one who can't read. Sigh.
-
@ronin said:
Yes, we've already firmly established that you're too prejudiced to accept the reasons Excel was specified. That's why you're ascribing clearly unreasonable motives to someone you've never met or interacted with. (Because you admitted to start with that it's a secondhand story.)TDWTF123, I think you imagine the task to be a lot simpler than it is, which is not your fault, considered that I haven't given very much information about its complexity.
Anyway, I don't deny that it would be possible to implement some solution that uses both Excel and the partner's web service (even if it would need a lot of VBA, IMHO taking surely about the same effort as doing it in a real programming language).
But that's not the point at all. The manager didn't say she wanted any implementation as long as it involved Excel. Instead, she wanted exactly the implementation that was specified in her concept. And even if there was a simple, clever and maintainable way to do it in Excel, I highly doubt that it was in her concept, so it would have been equally rejected.
She didn't choose Excel because she had made the informed decision that it was the better solution. She chose it because it was the only IT-ish thing she knew.
My suspicion is that all what mattered to her was to play a vital role in the project so she could take the credit of the its success, even if that meant to do a job that she wasn't qualified for and that wasn't in her responsibility. When the IT project managers created their own concept (which is actually their job) and had it implemented (thereby reducing the importance of her contribution), the project became useless to her, and before she let someone else take any credit, she could as well scrap it altogether. Typical PHB behaviour.
Run this hypothesis and see where it goes: the manager had a good reason to request Excel, since it's part of the existing workflow; completing the project in Excel is trivial; she was told that instead of implementing the trivial solution, only an expensive custom solution would suffice, and in any case would be unable to integrate with the workflow as required. The manager then cancels and complains that her project was sabotaged.
Every step in that chain makes complete sense. The simplest of hypotheses explains every WTF you raised. Occam's razor says that your colleague who told you the story misunderstood the requirements on a project and fucked it up as a result. Given that such a misunderstanding would be a good example of the most common failure mode of all projects, it's not like we're introducing anything you might describe as unlikely.
-
All I can say is, WTF? He is the prejudiced one? From what we knew from the first message there was NOT ONE SINGLE REASON that pointed to Excel being better for what he needed to do. But for some reason you insisted. And now he shows up, and says that "no, I know what you mean, but it wouldn't really have been appropriate here" and apparently you're more convinced that he's an idiot and doesn't know what he wants?
The only explanation I see is that you're assuming that the manager was knowledgeable in computers and had an existing "workflow" and there is no other possible reason why she would have cancelled the project in anger, whereas everyone else started assuming that she's just an egotistical idiot that wanted it done her way or no way like the dozens we see on this website every day.
This thread is worse than that other where OP found a procedure that made >100,000 useless database queries (and deleted them) and everyone was like "BUT WHAT IF THERE'S A CACHE THAT WAS BEING FED BY THOSE QUERIES".
-
@anonymous235 said:
From what we knew from the first message there was NOT ONE SINGLE REASON that pointed to Excel being better for what he needed to do.
Not if you're too prejudiced to accept that Excel was the right answer, no. Otherwise, the fact that the client specified Excel is a damn good reason to think it was required. It's possible the client was insanely stupid, but it's also possible that the requirements were misunderstood. So which is it?@anonymous235 said:
everyone else started assuming that she's just an egotistical idiot that wanted it done her way or no way like the dozens we see on this website every day.
Firstly, not everyone. The people who actually know Excel are all saying the same thing as me. Secondly, no, we don't get dozens like that every day. We get the odd one or two. Misunderstanding requirements is orders of magnitude more common than outright insanity. Occam's razor says it's almost certainly the former and not the latter.@anonymous235 said:
And now he shows up, and says that "no, I know what you mean, but it wouldn't really have been appropriate here" and apparently you're more convinced that he's an idiot and doesn't know what he wants?
Yes, he's now explained in more detail and confirmed what several people clearly suspected initially: that he doesn't know anything about Excel's capabilities, and is indeed ignorantly prejudiced against it.
@ronin said:it would need a lot of VBA, IMHO taking surely about the same effort as doing it in a real programming language).
-
@TDWTF123 said:
Yes, he's now explained in more detail and confirmed what several people clearly suspected initially: that he doesn't know anything about Excel's capabilities, and is indeed ignorantly prejudiced against it.
Now I'm suspecting that in his less lucid moments, TDWTF123 maintains a VB5 desktop search application and loves to take videos.
-
@TDWTF123 said:
Otherwise, the "fact" that the client specified Excel is a damn good reason to think it was required. It's possible the client was insanely stupid, but it's also possible that the requirements were misunderstood. So which is it?
Added scare quotes for you. It's c) the client didn't specify Excel, the clueless manager inserted that somewhere in the game of Chinese Whispers.
-
@joe.edwards said:
It's c) the client didn't specify Excel, the clueless manager inserted that somewhere in the game of Chinese Whispers.
WTF? The client and the manager are the same person.
-
@TDWTF123 said:
@joe.edwards said:
No. At least I did not read it that way. I read it as, the manager is a manager within the consultant's own company; she was the liaison between his company and the client. Only you and the one or two people agreeing with you appear to believe that she worked for the client.It's c) the client didn't specify Excel, the clueless manager inserted that somewhere in the game of Chinese Whispers.
WTF? The client and the manager are the same person.The OP stated that the client has a well-defined web API for this purpose. In a subsequent post, he stated that the client did not want Excel, and probably would have canceled the project if it had been implemented using the business manager's Excel solution. This seems to imply that there was some direct communication between the OP and the client, bypassing the account manager, but this is not clear.
OTOH, you could argue that the account manager is the IT department's (internal) client, and they should have satisfied her WTF requirements regardless of what the ultimate client wanted. Let her take the blame for failing to satisfy their requirements.
Of course, this story is now third-hand – lots of places for possible miscommunication and misunderstanding. The argument seems to stem from some people understanding $manager == $client, while others believe $manager != $client, which gives an entirely different understanding of whether the project requirements were reasonable.
-
@TDWTF123 said:
@joe.edwards said:
It's c) the client didn't specify Excel, the clueless manager inserted that somewhere in the game of Chinese Whispers.
WTF? The client and the manager are the same person.So I was right to mock your reading comprehension. I apologize for calling you a troll.
-
@HardwareGeek said:
you could argue that the account manager is the IT department's (internal) client
I wouldn't bother to argue the toss if you don't like the use of language. I meant the person commissioning the work, who had the power to cancel it because she wasn't happy, whatever you'd like to call her.
To my understanding, though, the work being commissioned was not for sale to a third party, but to facilitate doing some other business with them.
-
@HardwareGeek said:
@TDWTF123 said:
@joe.edwards said:
No. At least I did not read it that way. I read it as, the manager is a manager within the consultant's own company; she was the liaison between his company and the client. Only you and the one or two people agreeing with you appear to believe that she worked for the client.It's c) the client didn't specify Excel, the clueless manager inserted that somewhere in the game of Chinese Whispers.
WTF? The client and the manager are the same person.The OP stated that the client has a well-defined web API for this purpose. In a subsequent post, he stated that the client did not want Excel, and probably would have canceled the project if it had been implemented using the business manager's Excel solution. This seems to imply that there was some direct communication between the OP and the client, bypassing the account manager, but this is not clear.
OTOH, you could argue that the account manager is the IT department's (internal) client, and they should have satisfied her WTF requirements regardless of what the ultimate client wanted. Let her take the blame for failing to satisfy their requirements.
Of course, this story is now third-hand – lots of places for possible miscommunication and misunderstanding. The argument seems to stem from some people understanding $manager == $client, while others believe $manager != $client, which gives an entirely different understanding of whether the project requirements were reasonable.
The OP's said that an account manager decided to scrap a multi-million dollars project because IT did not want to implement her Excel solution. His conclusion is that she did that because she is a stupid PHB and either wanted all the glory or wanted the project to die. This is not how things work even in the most cut-throat organizations; from a political point of view she would have gained some credit whether IT implemented her Excel solution or some other solution, and she would also have gained some kind of clout if IT had opted for a different solution and failed. The only reason why it would make sense for her to cancel the project and blame IT was if she later discovered some flaw in the business opportunity and used IT as a scapegoat, avoiding the disaster and scoring minor political points for being yet another victim of IT.
That's why IT fucked up by refusing to go with the Excel solution. Given all the probable outcomes it was the only way to minimize risk and maximize potential gains, and in addition to that IT would have shown that they can be team players by biting the bullet and agreeing to come back at a later date to review the Excel solution once dollars were rolling in. If the project had to die because of a newly discovered flaw, the account manager would have had to either come clean or clue in IT and work out some backroom deal to blame the counterparty (been there, done that).
You don't play bad cop, especially with bullies. You go along, paper-trail everything, and *if* there is a significant risk for the business you call in a consensus building meeting where important stakeholders go on the record and make a decision.
One more thing: contrary to what many IT people think, work is not all rainbows and unicorns for managers. They often face a significant amount of pressure and have to use whatever shitty card they are dealt, just like sysadmins having to support Lotus Notes or programmers having to maintain an ancient codebase barfed over by generations of interns. So when a manager is apparently behaving in an erratic way, there are usually lots of more likely reasons than plain stupidity, greed or booze. Managers are lied to all the time, they have to deal with big black boxes (IT, accounting, engineering, HR) and they are judged by their superiors on many things that they have no control over (such as ballooning costs, blown deadlines, etc). When you deal with managers you have to consider this before just calling them stupid and stonewalling them, otherwise this will end up hurting all involved parties.
-
TDWTF123, I thought at first you were just misunderstanding, but now it seems you begin to fantasize outright. I know I didn't give you much detail about the systems, the workflows, the management structures etc., but that doesn't mean that it's OK for you to make that detail up and judge the situation based on wild speculation.
You don't know anything about the systems involved, the amout of data to be transferred, the complexity of our products, or the frequency of change, etc. I can't imagine why you think that Excel is the perfect solution here (except if you think that Excel is the perfect solution for everything).
It's not true that Excel is part of the workflow. It's also not true that I've never met or interacted with the said manager. Where did you get that idea? I've worked with her on a few occasions, and my impression was that it's not very easy to get along with her. It seems that her idea of collaboration is that she gives orders and other people follow them.
To clarify further, if anybody cares:
* The IT project manager, the business manager (officially: head of supply chain management) and I all work in the same company. It is not a consulting company.
* The head of supply chain management was tasked by her higher-ups to manage the business side of the cooperation.
* No specific person working with the partner company has been mentioned. The colleague who told me the story only said that he and his team had called the partner about the proposed Excel solution, and the partner had asked why they didn't use the web service API instead. As I've been told in the meantime, the partner was apparently unaware that an Excel solution was in discussion previous to that call.
* The head of supply chain management who created the Excel based concept has no IT background whatsoever, while the IT project manager has a degree in computer science. I don't know what brings you, TDWTF123, to believe that she can judge the viability of a concept, be it involving Excel or not, better than he can.
I've meanwhile talked to the colleague again and asked him why he didn't simply implement the Excel concept. After all, it wouldn't have been his fault if it hadn't worked. His answer was that:
1. He was totally surprised by the reaction of our manager. He thought that by implementing a concept that was suggested by the partner, and that he deemed easier to implement and maintain, he'd do her a favor.
2. He decided againts implementing a cumbersome, error-prone and hard to maintain process because it would have bound his resources in form of developer's work time; resources he would need for subsequent projects.
3. He knew from experience that implementing a mediocre solution and then improving it as soon as its flaws show is not an option. Given the short attention span of our management, they're not very inclined to let you re-visit a project that has already been labeled "mission accomplished". They simply won't give you the time to do that when you're up to the ears in other, newer, more important projects (new projects are always more important than past ones). Once an implementation is in place, you're stuck with it.
4. I don't know how often I'll have to repeat that, but the main reason for not using the Excel concept was that the partner didn't want it.
Ronald, concerning your response, I acknowledge that managers also are under pressure and their motives aren't always as crazy as they seem to people outside of the process of decision. Maybe I'm doing her wrong to suspect that she reacted irrationally and/or selfishly, but when I compare her personality as far as I know her, that's at least a possibility. I also can't imagine any other reason why she should create an IT concept in the first place while it's definitely not her responsibility.
I've worked with a lot of managers here, and most of them are wise enough to leave the creation of IT concepts entirely to those who were hired specially to do it, or, if they think they absolutely have to make one by themselves, at least listen to advice from the IT people. Then, however, there are a few who think they have to micro-manage everything and will take any objection as a personal insult. The reaction to cancel a whole project is extreme but not entirely implausible for some personalities.
-
@ronin said:
The head of supply chain management who created the Excel based concept has no IT background whatsoever, while the IT project manager has a degree in computer science.
But that doesn't necessarily mean that either of them have any IT background!CS isn't IT, just as physics isn't engineering or, more accurately, manufacturing. OTOH, some people with CS backgrounds do very well in IT; it all depends on what people want to achieve and how they think about the world.
-
@ronin said:
TDWTF123, I thought at first you were just misunderstanding, but now it seems you begin to fantasize outright. I know I didn't give you much detail about the systems, the workflows, the management structures etc., but that doesn't mean that it's OK for you to make that detail up and judge the situation based on wild speculation.
No, I'm basing it on everything you're telling us. You keep going around the chain of circular logic mentioned before.@ronin said:
You're continuing to make it abundantly clear that my explanation was almost certainly correct, and it is all down to prejudice.1. He was totally surprised by the reaction of our manager. He thought that by implementing a concept that was suggested by the partner, and that he deemed easier to implement and maintain, he'd do her a favor.
2. He decided againts implementing a cumbersome, error-prone and hard to maintain process because it would have bound his resources in form of developer's work time; resources he would need for subsequent projects.
3. He knew from experience that implementing a mediocre solution and then improving it as soon as its flaws show is not an option. Given the short attention span of our management, they're not very inclined to let you re-visit a project that has already been labeled "mission accomplished". They simply won't give you the time to do that when you're up to the ears in other, newer, more important projects (new projects are always more important than past ones). Once an implementation is in place, you're stuck with it.
4. I don't know how often I'll have to repeat that, but the main reason for not using the Excel concept was that the partner didn't want it.
- He was surprised by the reaction of the manager because he hadn't understood the job spec.
- He was too prejudiced to correctly analyse the impact of using Excel, ascribing problems to it that simply don't exist. He was also too prejudiced to correctly analyse the time-costs involved.
- He was too prejudiced to accept the obviously better solution, so he managed to convince himself (in the face of all the evidence) it was somehow worse or less maintainable.
- The partner wouldn't have needed to know, nor would they have cared. But you're too prejudiced against Excel to see how it would have worked.
We have now firmly established that all your objections to using Excel as requested by your internal client are entirely erroneous. In light of that, for you to keep insisting that there was some reason to use something other than Excel, it's very apparent that you're simply an anti-Excel bigot. Your WTF is not a WTF at all, except the part where your equally prejudiced colleague refused to do the work he's paid for out of mistaken 'principle'.
-
@TDWTF123 said:
You're continuing to make it abundantly clear that my explanation was almost certainly correct, and it is all down to prejudice.
work on your reading comprehension;1. He was surprised by the reaction of the manager because he hadn't understood the job spec.
2. He was too prejudiced to correctly analyse the impact of using Excel, ascribing problems to it that simply don't exist. He was also too prejudiced to correctly analyse the time-costs involved.
3. He was too prejudiced to accept the obviously better solution, so he managed to convince himself (in the face of all the evidence) it was somehow worse or less maintainable.
4. The partner wouldn't have needed to know, nor would they have cared. But you're too prejudiced against Excel to see how it would have worked.
We have now firmly established that all your objections to using Excel as requested by your internal client are entirely erroneous. In light of that, for you to keep insisting that there was some reason to use something other than Excel, it's very apparent that you're simply an anti-Excel bigot. Your WTF is not a WTF at all, except the part where your equally prejudiced colleague refused to do the work he's paid for out of mistaken 'principle'.
1. he was susrpised that the manager just killed the project because the guy didn't get his own way after dictating stuff that he shouldn't be dictating
2. you don't know the difference between working with a language you know and love to interface with a web API and creating and mailing excel sheets to and fro between companies for the rest of both companies' existence
3. he had more experience with interacting with a web interface than merging excel sheets and wanted to keepfuture work to a minimum
4 the proposed spec by the manager meant that the partner did need to know about the excel sheets:
@ronin said:
The problem with this manager's concept, however, was that it went well into the technical details, despite the fact that she had no idea about technical things. She only knew MS Excel, and so the concept involved a bunch of Excel sheets that would have to be exchanged between us and the other company, and regularly merged and maintained on either side - altogether a very cumbersome and error-prone semi-manual process.the only way to appease the guy would have been to create a excel frontend (as you seem to be suggesting), but that requires the backend interfacing to be competed, which is a slow process
-
TDWTF123, you seem to be referring to a whole different story. It seems you deliberately make up things I never said just to make it fit your Excel fanaticism.
- You said that I'd never met the manager who made the concept. Wrong.
- You also seem to believe that Excel is already part of our workflows. Wrong.
- You seem to believe that the supply chain manager's concept somehow involved using Excel as front end or interface between the systems, which I have repeatedly told you is wrong.
There's nothing more to be said. But feel free to continue beating up the straw man you've created.
-
@ratchet freak said:
2. you don't know the difference between working with a language you know and love to interface with a web API and creating and mailing excel sheets to and fro between companies for the rest of both companies' existence
Jesus, are you people blind? It's repeatedly been agreed by those of us who know Excel that the exact process needed tweaking to use the available features of Excel which make that unnecessary. Excel can quite happily interact with the partner's API. This has been explained repeatedly.
@ratchet freak said:3. he had more experience with interacting with a web interface than merging excel sheets and wanted to keepfuture work to a minimum
Yup, I agree, sheer incompetence and bigotry. He didn't want to learn the easy way to do things.
@ratchet freak said:4 the proposed spec by the manager meant that the partner did need to know about the excel sheets:
See the previous point. We've been over and over this. @ronin said:You also seem to believe that Excel is already part of our workflows. Wrong.
I call shenanigans. You're either lying on purpose now, or completely deluded.
@ronin said:You seem to believe that the supply chain manager's concept somehow involved using Excel as front end or interface between the systems, which I have repeatedly told you is wrong.
I haven't said that once. Your anti-Excel prejudice is so strong that you refuse to accept the correct way of doing things.
Like I keep telling you, the fixed Excel proposal was half an hour's work for someone who knows Excel. You haven't suggested at any point that the alternative was comparable in terms of resource commitment.
It's very obvious to anyone without prejudice that the manager cancelled the project not out of irrational spite, but because something that was supposed to be a quick job was suddenly being quoted as a major programming task because the programmers insisted on reinventing the wheel, the axle, the cart, the horse, and the road.
-
@TDWTF123 said:
Like I keep telling you, the fixed Excel proposal was half an hour's work for someone who knows Excel.
That's true, because all the work in the proposal was manual.
@TDWTF123 said:
It's very obvious to anyone without prejudice that the manager cancelled the project not out of irrational spite, but because something that was supposed to be a quick job was suddenly being quoted as a major programming task because the programmers insisted on reinventing the wheel, the axle, the cart, the horse, and the road.
I LOLed out loud here. No doubt they jammed their noodles, too!
-
TDWTF123, while Excel is clearly the superior solution on paper, having a manager request the perfect solution from people that can't produce it is pointless. If the manager wanted Excel gurus that knew how to create the kind of spreadsheets you talk about, she should have hired people with the right qualifications. She instead has an IT department that doesn't know how to create excel sheets.
Moreover, many of the same accusations leveled at the IT department can be leveled at the manager. If the IT department can only provide a crappy replacement for a glorious Excel spreadsheet, but that crappy replacement works, then the manager should have rolled her eyes at their incompetence and continued with the project. The OP story doesn't say that the IT team found problems with their approach, that they were over budget or late on delivering their solution. On the contrary, they were almost done. A proper manager, even one who knows that Excel was the right way to go, should have seen the project to completion. Or paid closer attention when she noticed that fifteen minutes had gone by and there was no preliminary Excel spreadsheet delivered, as she would have expected if they were going with Excel.
Even if the manager was IT's "client", the company is the manager's client, and she should have done what was best for the company even if she didn't get what she requested.
mod: re-added linebreaks –dh
-
@Kian said:
TDWTF123, while Excel is clearly the superior solution on paper
Except that there is no evidence that it is (and plenty of evidence against), aside from inside TDWTF123's imagination.
-
@TDWTF123 said:
I haven't said that once. Your anti-Excel prejudice is so strong that you refuse to accept the correct way of doing things.
Like I keep telling you, the fixed Excel proposal was half an hour's work for someone who knows Excel. You haven't suggested at any point that the alternative was comparable in terms of resource commitment
Bullshit. Go back and read the OP. OP's company has data stored in a database somewhere. They need to get that data out to another company. That other company helpfully has a webservice API. Where the fuck does excel even come into the scenario? Why would anyone even THINK about using excel to do this?
And how would using excel as a middle layer from the database to the other company have any savings whatsoever? They'd still have to learn the webservice API and figure out any integration issues. Just now you've added a layer of excel quirks to the process.
Unless your plan is to fiddle with the excel spreadsheets the data entry monkeys may or may not be using to put that data in the database in the first place. That's a bad idea for several reasons, and again runs into the problem of STILL needing to do the same work as the database-to-API scenario anyway.@TDWTF123 said:
It's very obvious to anyone without prejudice that the manager cancelled the project not out of irrational spite, but because something that was supposed to be a quick job was suddenly being quoted as a major programming task because the programmers insisted on reinventing the wheel, the axle, the cart, the horse, and the road.
The problem here is that it was ALWAYS going to be a major programming task. If she was thinking of it as a "quick job," then that was a stupid estimate by someone who isn't competent to make that determination. And if that's why she cancelled it, that is STILL a major management WTF.
