Co-worker team leader wants to inject his friend's awful software into our development. What should I say to...












103















In theory, he is on the same level as me. In practice, he is above me (as de-facto team-leader). I am working in development/devops, with a partial overlap with his projects.



We just had a meeting with the company wanting to sell this crap software to us. He invited me to this meeting, even though he had enough information about my preferences to know that I will likely strongly dislike the idea.



I started to write a mail to our boss, where I just say the truth, as I see it. The problem is that after I've read my own mail, it became clear that at the average company it would endanger my job. Thus I deleted this mail, without sending it.



In general, the company has an above-average friendly atmosphere what I consider a big value, and I don't want to poison it. The opinion of the subordinates also has an above-average effect to the higher-level decisions, I also consider that a big value here. In exchange, our wages are a little bit below average.



The problem is that the team-leader will now probably utilize his "influence" over the developers to support the idea, and thus influence the decision of our common boss. In this "indirect" way, he will probably be able to inject the crap software into the development.



I don't have the same influence.



But I need to do something. But what?










share|improve this question




















  • 3





    Comments are not for extended discussion; this conversation has been moved to chat.

    – Mister Positive
    Mar 13 at 18:44






  • 11





    What is this "crap software"? are we talking a library to meet a business need? IE: Aspose to process Word Documents? Or is it junk-ware that gets installed on the clients mahines? IE: "bonus offers" that come with Adobe Reader? Is it middle-ware that does stuff like Source Safe? Different approaches to different types of "crap software"...

    – WernerCD
    Mar 14 at 13:52













  • @WernerCD While I am happy on your curiosity and I would be glad to share more details behind a flask of beer, in our current context, these are not needed infos to answer the question.

    – Gray Sheep
    Mar 14 at 14:21








  • 19





    Shrug I think they are... They will determine the justification for the software and the arguments against said "softwares" both from a developer perspective and a business perspective.

    – WernerCD
    Mar 14 at 14:25











  • @WernerCD Yes. This point is part of the majority of the already written answers we can read here.

    – Gray Sheep
    Mar 14 at 14:26
















103















In theory, he is on the same level as me. In practice, he is above me (as de-facto team-leader). I am working in development/devops, with a partial overlap with his projects.



We just had a meeting with the company wanting to sell this crap software to us. He invited me to this meeting, even though he had enough information about my preferences to know that I will likely strongly dislike the idea.



I started to write a mail to our boss, where I just say the truth, as I see it. The problem is that after I've read my own mail, it became clear that at the average company it would endanger my job. Thus I deleted this mail, without sending it.



In general, the company has an above-average friendly atmosphere what I consider a big value, and I don't want to poison it. The opinion of the subordinates also has an above-average effect to the higher-level decisions, I also consider that a big value here. In exchange, our wages are a little bit below average.



The problem is that the team-leader will now probably utilize his "influence" over the developers to support the idea, and thus influence the decision of our common boss. In this "indirect" way, he will probably be able to inject the crap software into the development.



I don't have the same influence.



But I need to do something. But what?










share|improve this question




















  • 3





    Comments are not for extended discussion; this conversation has been moved to chat.

    – Mister Positive
    Mar 13 at 18:44






  • 11





    What is this "crap software"? are we talking a library to meet a business need? IE: Aspose to process Word Documents? Or is it junk-ware that gets installed on the clients mahines? IE: "bonus offers" that come with Adobe Reader? Is it middle-ware that does stuff like Source Safe? Different approaches to different types of "crap software"...

    – WernerCD
    Mar 14 at 13:52













  • @WernerCD While I am happy on your curiosity and I would be glad to share more details behind a flask of beer, in our current context, these are not needed infos to answer the question.

    – Gray Sheep
    Mar 14 at 14:21








  • 19





    Shrug I think they are... They will determine the justification for the software and the arguments against said "softwares" both from a developer perspective and a business perspective.

    – WernerCD
    Mar 14 at 14:25











  • @WernerCD Yes. This point is part of the majority of the already written answers we can read here.

    – Gray Sheep
    Mar 14 at 14:26














103












103








103


5






In theory, he is on the same level as me. In practice, he is above me (as de-facto team-leader). I am working in development/devops, with a partial overlap with his projects.



We just had a meeting with the company wanting to sell this crap software to us. He invited me to this meeting, even though he had enough information about my preferences to know that I will likely strongly dislike the idea.



I started to write a mail to our boss, where I just say the truth, as I see it. The problem is that after I've read my own mail, it became clear that at the average company it would endanger my job. Thus I deleted this mail, without sending it.



In general, the company has an above-average friendly atmosphere what I consider a big value, and I don't want to poison it. The opinion of the subordinates also has an above-average effect to the higher-level decisions, I also consider that a big value here. In exchange, our wages are a little bit below average.



The problem is that the team-leader will now probably utilize his "influence" over the developers to support the idea, and thus influence the decision of our common boss. In this "indirect" way, he will probably be able to inject the crap software into the development.



I don't have the same influence.



But I need to do something. But what?










share|improve this question
















In theory, he is on the same level as me. In practice, he is above me (as de-facto team-leader). I am working in development/devops, with a partial overlap with his projects.



We just had a meeting with the company wanting to sell this crap software to us. He invited me to this meeting, even though he had enough information about my preferences to know that I will likely strongly dislike the idea.



I started to write a mail to our boss, where I just say the truth, as I see it. The problem is that after I've read my own mail, it became clear that at the average company it would endanger my job. Thus I deleted this mail, without sending it.



In general, the company has an above-average friendly atmosphere what I consider a big value, and I don't want to poison it. The opinion of the subordinates also has an above-average effect to the higher-level decisions, I also consider that a big value here. In exchange, our wages are a little bit below average.



The problem is that the team-leader will now probably utilize his "influence" over the developers to support the idea, and thus influence the decision of our common boss. In this "indirect" way, he will probably be able to inject the crap software into the development.



I don't have the same influence.



But I need to do something. But what?







colleagues ethics software-development feedback review






share|improve this question















share|improve this question













share|improve this question




share|improve this question








edited Mar 14 at 17:28









user45266

1234




1234










asked Mar 13 at 12:56









Gray SheepGray Sheep

1,72031225




1,72031225








  • 3





    Comments are not for extended discussion; this conversation has been moved to chat.

    – Mister Positive
    Mar 13 at 18:44






  • 11





    What is this "crap software"? are we talking a library to meet a business need? IE: Aspose to process Word Documents? Or is it junk-ware that gets installed on the clients mahines? IE: "bonus offers" that come with Adobe Reader? Is it middle-ware that does stuff like Source Safe? Different approaches to different types of "crap software"...

    – WernerCD
    Mar 14 at 13:52













  • @WernerCD While I am happy on your curiosity and I would be glad to share more details behind a flask of beer, in our current context, these are not needed infos to answer the question.

    – Gray Sheep
    Mar 14 at 14:21








  • 19





    Shrug I think they are... They will determine the justification for the software and the arguments against said "softwares" both from a developer perspective and a business perspective.

    – WernerCD
    Mar 14 at 14:25











  • @WernerCD Yes. This point is part of the majority of the already written answers we can read here.

    – Gray Sheep
    Mar 14 at 14:26














  • 3





    Comments are not for extended discussion; this conversation has been moved to chat.

    – Mister Positive
    Mar 13 at 18:44






  • 11





    What is this "crap software"? are we talking a library to meet a business need? IE: Aspose to process Word Documents? Or is it junk-ware that gets installed on the clients mahines? IE: "bonus offers" that come with Adobe Reader? Is it middle-ware that does stuff like Source Safe? Different approaches to different types of "crap software"...

    – WernerCD
    Mar 14 at 13:52













  • @WernerCD While I am happy on your curiosity and I would be glad to share more details behind a flask of beer, in our current context, these are not needed infos to answer the question.

    – Gray Sheep
    Mar 14 at 14:21








  • 19





    Shrug I think they are... They will determine the justification for the software and the arguments against said "softwares" both from a developer perspective and a business perspective.

    – WernerCD
    Mar 14 at 14:25











  • @WernerCD Yes. This point is part of the majority of the already written answers we can read here.

    – Gray Sheep
    Mar 14 at 14:26








3




3





Comments are not for extended discussion; this conversation has been moved to chat.

– Mister Positive
Mar 13 at 18:44





Comments are not for extended discussion; this conversation has been moved to chat.

– Mister Positive
Mar 13 at 18:44




11




11





What is this "crap software"? are we talking a library to meet a business need? IE: Aspose to process Word Documents? Or is it junk-ware that gets installed on the clients mahines? IE: "bonus offers" that come with Adobe Reader? Is it middle-ware that does stuff like Source Safe? Different approaches to different types of "crap software"...

– WernerCD
Mar 14 at 13:52







What is this "crap software"? are we talking a library to meet a business need? IE: Aspose to process Word Documents? Or is it junk-ware that gets installed on the clients mahines? IE: "bonus offers" that come with Adobe Reader? Is it middle-ware that does stuff like Source Safe? Different approaches to different types of "crap software"...

– WernerCD
Mar 14 at 13:52















@WernerCD While I am happy on your curiosity and I would be glad to share more details behind a flask of beer, in our current context, these are not needed infos to answer the question.

– Gray Sheep
Mar 14 at 14:21







@WernerCD While I am happy on your curiosity and I would be glad to share more details behind a flask of beer, in our current context, these are not needed infos to answer the question.

– Gray Sheep
Mar 14 at 14:21






19




19





Shrug I think they are... They will determine the justification for the software and the arguments against said "softwares" both from a developer perspective and a business perspective.

– WernerCD
Mar 14 at 14:25





Shrug I think they are... They will determine the justification for the software and the arguments against said "softwares" both from a developer perspective and a business perspective.

– WernerCD
Mar 14 at 14:25













@WernerCD Yes. This point is part of the majority of the already written answers we can read here.

– Gray Sheep
Mar 14 at 14:26





@WernerCD Yes. This point is part of the majority of the already written answers we can read here.

– Gray Sheep
Mar 14 at 14:26










12 Answers
12






active

oldest

votes


















274















But something I need to do. But what?




Provide your feedback in a "constructive way", and be done about it. Not your place to make decisions.



Mention something along the lines of




"It was good to get a chance to evaluate the product X. As I see it:



- Pros: 1, 2, 3



- Cons: 1, 2, 3, 4, 5, 6, 7, 8, 9, ......



As it is evident from the analysis above, the list of cons overwhelms the list of pros, overall, I'd not be inclined to use this.



There might be better alternative which could have a reverse result of the given assessment, please let me know if you'd need me to work on that."




You were invited to the meeting (and the demo, I guess), and you have a fair idea of the ups and downs. You report them, solely based on the merits and demerits. Leave the decision making part to the people who are taking them.



At a later point of time if it comes back in the form that "even-after-new-tool-why-productivity-is-down" argument, well, you'll have your "proof".






share|improve this answer





















  • 149





    Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

    – UKMonkey
    Mar 13 at 15:16






  • 38





    +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

    – OnoSendai
    Mar 13 at 16:01






  • 21





    Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

    – David S.
    Mar 13 at 20:51






  • 12





    Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

    – Stig Hemmer
    Mar 14 at 8:17






  • 3





    Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

    – Paul Johnson
    Mar 15 at 11:37



















65














If you believe that a coworker is operating in cronyistic manner and playing fast and loose with company funds, yes, that is something you should raise with your manager.



Saying the software is "crap" is not likely to get you much traction. You must quantify how it is substandard, and how the business will not get the appropriate value for money. Just as you are annoyed that your teamleader is not objective, you must be objective yourself.



For example, you can contrast this "crap" software with competitor offerings. You could also estimate the value to the code base in saved man-hours.



It's possible you were invited along to provide the illusion of objectivity. If your "teamleader" picked you because he knew you may be "cautious" to bring up this with your manager, and thus he gets implicit validation from your presence.



"@GraySheep was there and he didn't raise any concerns"



You don't want to be silent and have the truth to come out.






share|improve this answer





















  • 7





    If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

    – Gregory Currie
    Mar 13 at 14:43






  • 2





    I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

    – Gregory Currie
    Mar 13 at 14:45






  • 19





    Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

    – corsiKa
    Mar 13 at 15:11






  • 1





    @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

    – Gray Sheep
    Mar 13 at 17:33






  • 3





    @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

    – Graham
    Mar 13 at 22:19



















18














(Good) management is influenced by logic, not name-calling. Reading your OP, you have mentioned that you think this software is crap, but you didn't say how or why. If I was a manager and I read your OP, I would think you were just a troublemaker, and you would lose face with me. If this is how you wrote the email to management, then it's a good thing you didn't send it.



What you want to do is lay out, plainly and objectively, what your objections are. Maybe you have a use case that this software doesn't satisfy? Maybe the software is too slow or doesn't meet other benchmarks? Maybe the support isn't there for it, so technical issues that arise would be hard to resolve? Maybe it's just plain buggy? Whatever the problems are, explain them in a clear and detailed way to management. Don't use words like "crap" or "horrible" or whatever; those are weasel words and don't mean anything. Outline your concerns, and let your concerns speak for themselves.






share|improve this answer
























  • Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

    – Gray Sheep
    Mar 13 at 18:04



















15















But something I need to do. But what?




First thing constructive to do is to check your motivations carefully, why do you need to do something? Why do you want to engage in a dispute that you think you will lose.



If you're asked to analyse a tool, do so, give the pro's and cons without bias. Don't create problems without complete analysis or reason.






share|improve this answer





















  • 9





    @GraySheep Those are two personal reasons. You need to make this about the business.

    – Gregory Currie
    Mar 13 at 13:10






  • 7





    @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

    – Gregory Currie
    Mar 13 at 13:15






  • 4





    @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

    – Gregory Currie
    Mar 13 at 13:21






  • 10





    @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

    – Gregory Currie
    Mar 13 at 13:40






  • 7





    It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

    – Rich
    Mar 13 at 20:39





















10














Rewrite the letter you were going to send your boss.



Don't assume bad intentions from your coworker.



Be polite. Be specific. Drop the word "crap". Give your honest but detailed evaluation and be able to back up every point you raise, and ideally put an example of each point in the letter.



Boss,

I've reviewed the code being offered and I view it as sub-standard for the following reasons...

1) Reason #1. Reason for thinking this is a problem. Example.



(Sample) 1) There are no comments in the code. They have X lines of code. I did a grep search and found a grand total of Y comment lines. For perspective our current code base has...






share|improve this answer



















  • 3





    Point taken, though some people don't consider comment line % a great indicator of code quality :)

    – Gregory Currie
    Mar 13 at 13:19











  • @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

    – Dark Matter
    Mar 13 at 13:21








  • 3





    If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

    – Gregory Currie
    Mar 13 at 13:25






  • 1





    @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

    – Gregory Currie
    Mar 13 at 14:48








  • 3





    @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

    – jamesqf
    Mar 13 at 16:46



















5















He invited me to this meeting, even though he had enough information from my preferences to know that I will likely strongly dislike the idea.




Perhaps he is feeling pressured by his friends to put their software forward, even though he may not like it himself. He could be hoping that someone else will notice its flaws.



I might talk to him directly (depending on our relationship) and try to determine what he really thinks. I would also try to point out the flaws in more neutral language than 'crap' software.






share|improve this answer
























  • Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

    – Paul Johnson
    Mar 15 at 11:35



















3














You call this software "crap" a couple of times, so you clearly know a thing or two about what it does, and what your company actually needs. Write up a document (email) outlining your concerns about the features / functionality, and send it to your boss.



I would suggest also offering alternatives, such that you're not simply coming across as jealous, or negative. Make a table analyzing features, pricing, etc.




Some options that don't share the same risks are X, and Y. The pricing for X is a little higher than the option proposed by John, but offers these advantages: ...




At the very end of the email you may include a phrase along the lines of:




As you can see, there are solid reasons why we should continue looking for a product to fill this niche. Furthermore I fear that John's decision to recommend this software may be influenced by the fact that a close personal friend of his created it.




You may want to hold that tidbit of information in reserve just in case you have to escalate, however.






share|improve this answer
























  • Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

    – Gray Sheep
    Mar 13 at 17:02





















3














Talk about it with your colleague/unofficial teamleader.



You think he knows your opinion about the topic but it may not be this way.



He invited you to the meeting which means he values your opinion. (I assume here that he didn't invite you to taunt you because your high opinion on the good working climate)



Tell him directly that the software he wants to introduce would, in your opinion, hinder further development of the project.
The cause for his support for the software in question might be personal, which he should overthink.
If this isn't the case ask him to explain to you why he thinks the software will improve the development.



A normal discussion about work related topic which does affect your work shouldn't cause danger to your employment or social status in your company.
It might even improve because you show compassion for your work.



But most importantly: You do it professional.



EDIT1: If your colleague does not show any kind of good reasoning talk about it with your manager afterwards. Maybe propose a three-way discussion to get the topic dealt with fast.






share|improve this answer





















  • 4





    He could also have been invited to give the illusion of objectivity.

    – Gregory Currie
    Mar 13 at 13:22






  • 2





    Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

    – GittingGud
    Mar 13 at 13:28






  • 1





    I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

    – Gregory Currie
    Mar 13 at 13:31



















3














Your colleague has a conflict of interest. You should discuss this with the other members of your organization, and make sure that the software is properly evaluated by a party without vested interest and free from undue influence.






share|improve this answer
























  • A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

    – Gray Sheep
    Mar 13 at 18:02



















2














If his friend doesn't work for the company, then injecting his buds software into the company's workflow is simply a conflict of interest. Pointing that out would help a lot.



I'd also explain to my boss why this software is crap and I'd try to provide some cost benefits analysis of using it. I'd even go so far as to attempt to show how much money the company will lose from the lost development time dealing with the unmaintainable can of worms your team lead's friend is trying to pass off as code. That should help too.



You are going above your team leads head though, so this likely won't have the greatest impact on your career at your current company. You're a dev though; you can always get another job, that will probably come with a pay raise, so you shouldn't be scared in situations like these.






share|improve this answer
























  • I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

    – Gray Sheep
    Mar 13 at 16:53













  • Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

    – Gray Sheep
    Mar 13 at 17:15








  • 1





    @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

    – Steve
    Mar 13 at 17:19






  • 2





    Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

    – Gray Sheep
    Mar 13 at 18:01






  • 1





    @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

    – Steve
    Mar 14 at 15:22



















1














make questions.



identify some issue that will arise using that software and ask how it will be handled.




we support multiple platforms but this tool does not: how this will be handled? we're leaving development on platform X that's the core of our customer base?



this new tool is licensed under license X that is not compatible with our product: a rewrite of our license may be required?



we're automating task X, Y and Z with a cut to the costs of 15% but this new tool is not compatible with current automation software: which automation solution we have to acquire to achieve the same goal?




management pay attention to costs but usually does not care about technicalities; if you can provide a few heavy questions with visible costs attached your point can get across easily.



make too many or too silly/whyning questions and you will lose any traction from now on and will be labeled as troublemaker.






share|improve this answer































    0














    You mention this software being awful, crap as you call it.



    Prove it!



    Crap software is:




    • very unstable (what if you let it run with a lot of requests at the same time) => perform load tests

    • very picky on input data/parameters (when you enter a string where a number is expected, the whole thing crashes).

    • from a developer point of view, very heavily maintainable : imagine that somebody requests a change, how many time is needed for developing an obvious modification?

    • not user friendly (how should it look like?)

    • wasting resources (how long does it take for making the easiest of calculations, how many memory does it use up, ...?)


    I understand: setting up an environment for proving the bad quality of this software might take some time, so in order to convince management, you might inform management about your doubts and request for some time to prepare the testing environment (in case this is not available yet).






    share|improve this answer


























    • This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

      – Gray Sheep
      Mar 15 at 9:47










    protected by Mister Positive Mar 14 at 0:04



    Thank you for your interest in this question.
    Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



    Would you like to answer one of these unanswered questions instead?














    12 Answers
    12






    active

    oldest

    votes








    12 Answers
    12






    active

    oldest

    votes









    active

    oldest

    votes






    active

    oldest

    votes









    274















    But something I need to do. But what?




    Provide your feedback in a "constructive way", and be done about it. Not your place to make decisions.



    Mention something along the lines of




    "It was good to get a chance to evaluate the product X. As I see it:



    - Pros: 1, 2, 3



    - Cons: 1, 2, 3, 4, 5, 6, 7, 8, 9, ......



    As it is evident from the analysis above, the list of cons overwhelms the list of pros, overall, I'd not be inclined to use this.



    There might be better alternative which could have a reverse result of the given assessment, please let me know if you'd need me to work on that."




    You were invited to the meeting (and the demo, I guess), and you have a fair idea of the ups and downs. You report them, solely based on the merits and demerits. Leave the decision making part to the people who are taking them.



    At a later point of time if it comes back in the form that "even-after-new-tool-why-productivity-is-down" argument, well, you'll have your "proof".






    share|improve this answer





















    • 149





      Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

      – UKMonkey
      Mar 13 at 15:16






    • 38





      +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

      – OnoSendai
      Mar 13 at 16:01






    • 21





      Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

      – David S.
      Mar 13 at 20:51






    • 12





      Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

      – Stig Hemmer
      Mar 14 at 8:17






    • 3





      Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

      – Paul Johnson
      Mar 15 at 11:37
















    274















    But something I need to do. But what?




    Provide your feedback in a "constructive way", and be done about it. Not your place to make decisions.



    Mention something along the lines of




    "It was good to get a chance to evaluate the product X. As I see it:



    - Pros: 1, 2, 3



    - Cons: 1, 2, 3, 4, 5, 6, 7, 8, 9, ......



    As it is evident from the analysis above, the list of cons overwhelms the list of pros, overall, I'd not be inclined to use this.



    There might be better alternative which could have a reverse result of the given assessment, please let me know if you'd need me to work on that."




    You were invited to the meeting (and the demo, I guess), and you have a fair idea of the ups and downs. You report them, solely based on the merits and demerits. Leave the decision making part to the people who are taking them.



    At a later point of time if it comes back in the form that "even-after-new-tool-why-productivity-is-down" argument, well, you'll have your "proof".






    share|improve this answer





















    • 149





      Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

      – UKMonkey
      Mar 13 at 15:16






    • 38





      +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

      – OnoSendai
      Mar 13 at 16:01






    • 21





      Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

      – David S.
      Mar 13 at 20:51






    • 12





      Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

      – Stig Hemmer
      Mar 14 at 8:17






    • 3





      Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

      – Paul Johnson
      Mar 15 at 11:37














    274












    274








    274








    But something I need to do. But what?




    Provide your feedback in a "constructive way", and be done about it. Not your place to make decisions.



    Mention something along the lines of




    "It was good to get a chance to evaluate the product X. As I see it:



    - Pros: 1, 2, 3



    - Cons: 1, 2, 3, 4, 5, 6, 7, 8, 9, ......



    As it is evident from the analysis above, the list of cons overwhelms the list of pros, overall, I'd not be inclined to use this.



    There might be better alternative which could have a reverse result of the given assessment, please let me know if you'd need me to work on that."




    You were invited to the meeting (and the demo, I guess), and you have a fair idea of the ups and downs. You report them, solely based on the merits and demerits. Leave the decision making part to the people who are taking them.



    At a later point of time if it comes back in the form that "even-after-new-tool-why-productivity-is-down" argument, well, you'll have your "proof".






    share|improve this answer
















    But something I need to do. But what?




    Provide your feedback in a "constructive way", and be done about it. Not your place to make decisions.



    Mention something along the lines of




    "It was good to get a chance to evaluate the product X. As I see it:



    - Pros: 1, 2, 3



    - Cons: 1, 2, 3, 4, 5, 6, 7, 8, 9, ......



    As it is evident from the analysis above, the list of cons overwhelms the list of pros, overall, I'd not be inclined to use this.



    There might be better alternative which could have a reverse result of the given assessment, please let me know if you'd need me to work on that."




    You were invited to the meeting (and the demo, I guess), and you have a fair idea of the ups and downs. You report them, solely based on the merits and demerits. Leave the decision making part to the people who are taking them.



    At a later point of time if it comes back in the form that "even-after-new-tool-why-productivity-is-down" argument, well, you'll have your "proof".







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 14 at 4:58









    iBug

    11116




    11116










    answered Mar 13 at 12:59









    Sourav GhoshSourav Ghosh

    7,00643254




    7,00643254








    • 149





      Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

      – UKMonkey
      Mar 13 at 15:16






    • 38





      +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

      – OnoSendai
      Mar 13 at 16:01






    • 21





      Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

      – David S.
      Mar 13 at 20:51






    • 12





      Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

      – Stig Hemmer
      Mar 14 at 8:17






    • 3





      Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

      – Paul Johnson
      Mar 15 at 11:37














    • 149





      Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

      – UKMonkey
      Mar 13 at 15:16






    • 38





      +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

      – OnoSendai
      Mar 13 at 16:01






    • 21





      Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

      – David S.
      Mar 13 at 20:51






    • 12





      Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

      – Stig Hemmer
      Mar 14 at 8:17






    • 3





      Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

      – Paul Johnson
      Mar 15 at 11:37








    149




    149





    Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

    – UKMonkey
    Mar 13 at 15:16





    Since OP has already highlighted that they had a bias before the meeting even started; this might help them establish in their own mind if the product really is as bad as they think it is.

    – UKMonkey
    Mar 13 at 15:16




    38




    38





    +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

    – OnoSendai
    Mar 13 at 16:01





    +1, but I wish I could upvote more - namely because this answer covers the two most important aspects: Always put forth your assessment in a constructive, non-disparaging way and keep a paper (err, electron. err, you get the idea) trail.

    – OnoSendai
    Mar 13 at 16:01




    21




    21





    Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

    – David S.
    Mar 13 at 20:51





    Make sure you're comfortable with anyone in the company seeing anything you put in writing. It's very likely that the other team lead will see what you wrote, so write it in an impartial voice, presenting facts and not opinions.

    – David S.
    Mar 13 at 20:51




    12




    12





    Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

    – Stig Hemmer
    Mar 14 at 8:17





    Just copy the mail to the other lead yourself, in fact add everybody who was at that meeting. It will seem more impartial that way.

    – Stig Hemmer
    Mar 14 at 8:17




    3




    3





    Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

    – Paul Johnson
    Mar 15 at 11:37





    Suggesting that the company should review competing products before making a decision is always a good move. Put a list of candidates in your memo to the boss.

    – Paul Johnson
    Mar 15 at 11:37













    65














    If you believe that a coworker is operating in cronyistic manner and playing fast and loose with company funds, yes, that is something you should raise with your manager.



    Saying the software is "crap" is not likely to get you much traction. You must quantify how it is substandard, and how the business will not get the appropriate value for money. Just as you are annoyed that your teamleader is not objective, you must be objective yourself.



    For example, you can contrast this "crap" software with competitor offerings. You could also estimate the value to the code base in saved man-hours.



    It's possible you were invited along to provide the illusion of objectivity. If your "teamleader" picked you because he knew you may be "cautious" to bring up this with your manager, and thus he gets implicit validation from your presence.



    "@GraySheep was there and he didn't raise any concerns"



    You don't want to be silent and have the truth to come out.






    share|improve this answer





















    • 7





      If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

      – Gregory Currie
      Mar 13 at 14:43






    • 2





      I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

      – Gregory Currie
      Mar 13 at 14:45






    • 19





      Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

      – corsiKa
      Mar 13 at 15:11






    • 1





      @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

      – Gray Sheep
      Mar 13 at 17:33






    • 3





      @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

      – Graham
      Mar 13 at 22:19
















    65














    If you believe that a coworker is operating in cronyistic manner and playing fast and loose with company funds, yes, that is something you should raise with your manager.



    Saying the software is "crap" is not likely to get you much traction. You must quantify how it is substandard, and how the business will not get the appropriate value for money. Just as you are annoyed that your teamleader is not objective, you must be objective yourself.



    For example, you can contrast this "crap" software with competitor offerings. You could also estimate the value to the code base in saved man-hours.



    It's possible you were invited along to provide the illusion of objectivity. If your "teamleader" picked you because he knew you may be "cautious" to bring up this with your manager, and thus he gets implicit validation from your presence.



    "@GraySheep was there and he didn't raise any concerns"



    You don't want to be silent and have the truth to come out.






    share|improve this answer





















    • 7





      If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

      – Gregory Currie
      Mar 13 at 14:43






    • 2





      I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

      – Gregory Currie
      Mar 13 at 14:45






    • 19





      Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

      – corsiKa
      Mar 13 at 15:11






    • 1





      @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

      – Gray Sheep
      Mar 13 at 17:33






    • 3





      @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

      – Graham
      Mar 13 at 22:19














    65












    65








    65







    If you believe that a coworker is operating in cronyistic manner and playing fast and loose with company funds, yes, that is something you should raise with your manager.



    Saying the software is "crap" is not likely to get you much traction. You must quantify how it is substandard, and how the business will not get the appropriate value for money. Just as you are annoyed that your teamleader is not objective, you must be objective yourself.



    For example, you can contrast this "crap" software with competitor offerings. You could also estimate the value to the code base in saved man-hours.



    It's possible you were invited along to provide the illusion of objectivity. If your "teamleader" picked you because he knew you may be "cautious" to bring up this with your manager, and thus he gets implicit validation from your presence.



    "@GraySheep was there and he didn't raise any concerns"



    You don't want to be silent and have the truth to come out.






    share|improve this answer















    If you believe that a coworker is operating in cronyistic manner and playing fast and loose with company funds, yes, that is something you should raise with your manager.



    Saying the software is "crap" is not likely to get you much traction. You must quantify how it is substandard, and how the business will not get the appropriate value for money. Just as you are annoyed that your teamleader is not objective, you must be objective yourself.



    For example, you can contrast this "crap" software with competitor offerings. You could also estimate the value to the code base in saved man-hours.



    It's possible you were invited along to provide the illusion of objectivity. If your "teamleader" picked you because he knew you may be "cautious" to bring up this with your manager, and thus he gets implicit validation from your presence.



    "@GraySheep was there and he didn't raise any concerns"



    You don't want to be silent and have the truth to come out.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 13 at 13:23

























    answered Mar 13 at 13:11









    Gregory CurrieGregory Currie

    3,29061931




    3,29061931








    • 7





      If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

      – Gregory Currie
      Mar 13 at 14:43






    • 2





      I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

      – Gregory Currie
      Mar 13 at 14:45






    • 19





      Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

      – corsiKa
      Mar 13 at 15:11






    • 1





      @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

      – Gray Sheep
      Mar 13 at 17:33






    • 3





      @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

      – Graham
      Mar 13 at 22:19














    • 7





      If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

      – Gregory Currie
      Mar 13 at 14:43






    • 2





      I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

      – Gregory Currie
      Mar 13 at 14:45






    • 19





      Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

      – corsiKa
      Mar 13 at 15:11






    • 1





      @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

      – Gray Sheep
      Mar 13 at 17:33






    • 3





      @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

      – Graham
      Mar 13 at 22:19








    7




    7





    If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

    – Gregory Currie
    Mar 13 at 14:43





    If you didn't want to go behind the back, or can't trust management, the other option is not conflict. I would probably address an email to your "team-leader" and CC your manager and start with: "Thank you for giving me an opportunity to assist the business in assessing the suitability of solution Y from company Z. I have summerised my assessment below, and also a brief assessment of other options. I'm always free to discuss any of the points if you wish." Then give a breakdown on the pros/cons of the solution, and follow up with pros/cons of competing solutions. (Maybe not in as much depth).

    – Gregory Currie
    Mar 13 at 14:43




    2




    2





    I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

    – Gregory Currie
    Mar 13 at 14:45





    I wouldn't mention, at all, that they are friends with the "team-leader", or even treat them specially. Be objective. If you wanted to go behind the back of the team-leader, you can raise concerns with the manager, but he will probably ask you to prepare a list of pros/cons, so maybe the letter above is a starting point.

    – Gregory Currie
    Mar 13 at 14:45




    19




    19





    Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

    – corsiKa
    Mar 13 at 15:11





    Gregory's comment on "saying it is crap won't get you far" remains true even if the software is, indeed, a steaming pile of crap

    – corsiKa
    Mar 13 at 15:11




    1




    1





    @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

    – Gray Sheep
    Mar 13 at 17:33





    @GregroyCurrie I explained the facts in a short mail to the boss. I didn't use the word "crap" and any negative. I just explained that it wouldn't help and we should still use technology X, first because it is what the customer wants, and second because it is the common technology of the industry and the devs simply should learn it. No answer arrived, but I am sure that the boss read it.

    – Gray Sheep
    Mar 13 at 17:33




    3




    3





    @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

    – Graham
    Mar 13 at 22:19





    @GraySheep If you're invited to a meeting about something, you're implicitly expected to be involved in the outcome of that meeting. Not doing that would endanger your job in an average company. It's absolutely fine and expected for you to sometimes disagree with someone higher up than you. If they have the authority to choose otherwise, or if your boss chooses their option, you just have to go with it. That's the point of having a chain of command. But everyone does expect you to have a valid technical opinion, otherwise they wouldn't have hired you.

    – Graham
    Mar 13 at 22:19











    18














    (Good) management is influenced by logic, not name-calling. Reading your OP, you have mentioned that you think this software is crap, but you didn't say how or why. If I was a manager and I read your OP, I would think you were just a troublemaker, and you would lose face with me. If this is how you wrote the email to management, then it's a good thing you didn't send it.



    What you want to do is lay out, plainly and objectively, what your objections are. Maybe you have a use case that this software doesn't satisfy? Maybe the software is too slow or doesn't meet other benchmarks? Maybe the support isn't there for it, so technical issues that arise would be hard to resolve? Maybe it's just plain buggy? Whatever the problems are, explain them in a clear and detailed way to management. Don't use words like "crap" or "horrible" or whatever; those are weasel words and don't mean anything. Outline your concerns, and let your concerns speak for themselves.






    share|improve this answer
























    • Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

      – Gray Sheep
      Mar 13 at 18:04
















    18














    (Good) management is influenced by logic, not name-calling. Reading your OP, you have mentioned that you think this software is crap, but you didn't say how or why. If I was a manager and I read your OP, I would think you were just a troublemaker, and you would lose face with me. If this is how you wrote the email to management, then it's a good thing you didn't send it.



    What you want to do is lay out, plainly and objectively, what your objections are. Maybe you have a use case that this software doesn't satisfy? Maybe the software is too slow or doesn't meet other benchmarks? Maybe the support isn't there for it, so technical issues that arise would be hard to resolve? Maybe it's just plain buggy? Whatever the problems are, explain them in a clear and detailed way to management. Don't use words like "crap" or "horrible" or whatever; those are weasel words and don't mean anything. Outline your concerns, and let your concerns speak for themselves.






    share|improve this answer
























    • Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

      – Gray Sheep
      Mar 13 at 18:04














    18












    18








    18







    (Good) management is influenced by logic, not name-calling. Reading your OP, you have mentioned that you think this software is crap, but you didn't say how or why. If I was a manager and I read your OP, I would think you were just a troublemaker, and you would lose face with me. If this is how you wrote the email to management, then it's a good thing you didn't send it.



    What you want to do is lay out, plainly and objectively, what your objections are. Maybe you have a use case that this software doesn't satisfy? Maybe the software is too slow or doesn't meet other benchmarks? Maybe the support isn't there for it, so technical issues that arise would be hard to resolve? Maybe it's just plain buggy? Whatever the problems are, explain them in a clear and detailed way to management. Don't use words like "crap" or "horrible" or whatever; those are weasel words and don't mean anything. Outline your concerns, and let your concerns speak for themselves.






    share|improve this answer













    (Good) management is influenced by logic, not name-calling. Reading your OP, you have mentioned that you think this software is crap, but you didn't say how or why. If I was a manager and I read your OP, I would think you were just a troublemaker, and you would lose face with me. If this is how you wrote the email to management, then it's a good thing you didn't send it.



    What you want to do is lay out, plainly and objectively, what your objections are. Maybe you have a use case that this software doesn't satisfy? Maybe the software is too slow or doesn't meet other benchmarks? Maybe the support isn't there for it, so technical issues that arise would be hard to resolve? Maybe it's just plain buggy? Whatever the problems are, explain them in a clear and detailed way to management. Don't use words like "crap" or "horrible" or whatever; those are weasel words and don't mean anything. Outline your concerns, and let your concerns speak for themselves.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 13 at 15:52









    Ertai87Ertai87

    11.1k21331




    11.1k21331













    • Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

      – Gray Sheep
      Mar 13 at 18:04



















    • Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

      – Gray Sheep
      Mar 13 at 18:04

















    Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

    – Gray Sheep
    Mar 13 at 18:04





    Thanks. This is what I did. It probably won't have any effect, we will see on the long-term, what happens.

    – Gray Sheep
    Mar 13 at 18:04











    15















    But something I need to do. But what?




    First thing constructive to do is to check your motivations carefully, why do you need to do something? Why do you want to engage in a dispute that you think you will lose.



    If you're asked to analyse a tool, do so, give the pro's and cons without bias. Don't create problems without complete analysis or reason.






    share|improve this answer





















    • 9





      @GraySheep Those are two personal reasons. You need to make this about the business.

      – Gregory Currie
      Mar 13 at 13:10






    • 7





      @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

      – Gregory Currie
      Mar 13 at 13:15






    • 4





      @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

      – Gregory Currie
      Mar 13 at 13:21






    • 10





      @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

      – Gregory Currie
      Mar 13 at 13:40






    • 7





      It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

      – Rich
      Mar 13 at 20:39


















    15















    But something I need to do. But what?




    First thing constructive to do is to check your motivations carefully, why do you need to do something? Why do you want to engage in a dispute that you think you will lose.



    If you're asked to analyse a tool, do so, give the pro's and cons without bias. Don't create problems without complete analysis or reason.






    share|improve this answer





















    • 9





      @GraySheep Those are two personal reasons. You need to make this about the business.

      – Gregory Currie
      Mar 13 at 13:10






    • 7





      @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

      – Gregory Currie
      Mar 13 at 13:15






    • 4





      @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

      – Gregory Currie
      Mar 13 at 13:21






    • 10





      @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

      – Gregory Currie
      Mar 13 at 13:40






    • 7





      It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

      – Rich
      Mar 13 at 20:39
















    15












    15








    15








    But something I need to do. But what?




    First thing constructive to do is to check your motivations carefully, why do you need to do something? Why do you want to engage in a dispute that you think you will lose.



    If you're asked to analyse a tool, do so, give the pro's and cons without bias. Don't create problems without complete analysis or reason.






    share|improve this answer
















    But something I need to do. But what?




    First thing constructive to do is to check your motivations carefully, why do you need to do something? Why do you want to engage in a dispute that you think you will lose.



    If you're asked to analyse a tool, do so, give the pro's and cons without bias. Don't create problems without complete analysis or reason.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 13 at 13:12

























    answered Mar 13 at 13:07









    KilisiKilisi

    122k70269471




    122k70269471








    • 9





      @GraySheep Those are two personal reasons. You need to make this about the business.

      – Gregory Currie
      Mar 13 at 13:10






    • 7





      @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

      – Gregory Currie
      Mar 13 at 13:15






    • 4





      @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

      – Gregory Currie
      Mar 13 at 13:21






    • 10





      @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

      – Gregory Currie
      Mar 13 at 13:40






    • 7





      It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

      – Rich
      Mar 13 at 20:39
















    • 9





      @GraySheep Those are two personal reasons. You need to make this about the business.

      – Gregory Currie
      Mar 13 at 13:10






    • 7





      @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

      – Gregory Currie
      Mar 13 at 13:15






    • 4





      @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

      – Gregory Currie
      Mar 13 at 13:21






    • 10





      @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

      – Gregory Currie
      Mar 13 at 13:40






    • 7





      It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

      – Rich
      Mar 13 at 20:39










    9




    9





    @GraySheep Those are two personal reasons. You need to make this about the business.

    – Gregory Currie
    Mar 13 at 13:10





    @GraySheep Those are two personal reasons. You need to make this about the business.

    – Gregory Currie
    Mar 13 at 13:10




    7




    7





    @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

    – Gregory Currie
    Mar 13 at 13:15





    @GraySheep 1) Is being cross-platform important to your business? 2) Is free software important to your business? 3) What does this even mean?

    – Gregory Currie
    Mar 13 at 13:15




    4




    4





    @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

    – Gregory Currie
    Mar 13 at 13:21





    @GraySheep Those are excellent reasons. You should replace the term "crap" with "unsuitable" then :) And these are the type of things you should articulate in your letter.

    – Gregory Currie
    Mar 13 at 13:21




    10




    10





    @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

    – Gregory Currie
    Mar 13 at 13:40





    @GraySheep This all seems very personal for you. You need to adjust your mentality and shift towards acting (or at least seen to be acting) in the best interest of your employer.

    – Gregory Currie
    Mar 13 at 13:40




    7




    7





    It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

    – Rich
    Mar 13 at 20:39







    It sounds to me like you're just taking your co-worker's proposal personally because it might make you a redundant resource. Maybe the business simply values getting rid DevOps resources more than the other issues you suggest that the proposal will cause.

    – Rich
    Mar 13 at 20:39













    10














    Rewrite the letter you were going to send your boss.



    Don't assume bad intentions from your coworker.



    Be polite. Be specific. Drop the word "crap". Give your honest but detailed evaluation and be able to back up every point you raise, and ideally put an example of each point in the letter.



    Boss,

    I've reviewed the code being offered and I view it as sub-standard for the following reasons...

    1) Reason #1. Reason for thinking this is a problem. Example.



    (Sample) 1) There are no comments in the code. They have X lines of code. I did a grep search and found a grand total of Y comment lines. For perspective our current code base has...






    share|improve this answer



















    • 3





      Point taken, though some people don't consider comment line % a great indicator of code quality :)

      – Gregory Currie
      Mar 13 at 13:19











    • @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

      – Dark Matter
      Mar 13 at 13:21








    • 3





      If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

      – Gregory Currie
      Mar 13 at 13:25






    • 1





      @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

      – Gregory Currie
      Mar 13 at 14:48








    • 3





      @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

      – jamesqf
      Mar 13 at 16:46
















    10














    Rewrite the letter you were going to send your boss.



    Don't assume bad intentions from your coworker.



    Be polite. Be specific. Drop the word "crap". Give your honest but detailed evaluation and be able to back up every point you raise, and ideally put an example of each point in the letter.



    Boss,

    I've reviewed the code being offered and I view it as sub-standard for the following reasons...

    1) Reason #1. Reason for thinking this is a problem. Example.



    (Sample) 1) There are no comments in the code. They have X lines of code. I did a grep search and found a grand total of Y comment lines. For perspective our current code base has...






    share|improve this answer



















    • 3





      Point taken, though some people don't consider comment line % a great indicator of code quality :)

      – Gregory Currie
      Mar 13 at 13:19











    • @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

      – Dark Matter
      Mar 13 at 13:21








    • 3





      If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

      – Gregory Currie
      Mar 13 at 13:25






    • 1





      @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

      – Gregory Currie
      Mar 13 at 14:48








    • 3





      @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

      – jamesqf
      Mar 13 at 16:46














    10












    10








    10







    Rewrite the letter you were going to send your boss.



    Don't assume bad intentions from your coworker.



    Be polite. Be specific. Drop the word "crap". Give your honest but detailed evaluation and be able to back up every point you raise, and ideally put an example of each point in the letter.



    Boss,

    I've reviewed the code being offered and I view it as sub-standard for the following reasons...

    1) Reason #1. Reason for thinking this is a problem. Example.



    (Sample) 1) There are no comments in the code. They have X lines of code. I did a grep search and found a grand total of Y comment lines. For perspective our current code base has...






    share|improve this answer













    Rewrite the letter you were going to send your boss.



    Don't assume bad intentions from your coworker.



    Be polite. Be specific. Drop the word "crap". Give your honest but detailed evaluation and be able to back up every point you raise, and ideally put an example of each point in the letter.



    Boss,

    I've reviewed the code being offered and I view it as sub-standard for the following reasons...

    1) Reason #1. Reason for thinking this is a problem. Example.



    (Sample) 1) There are no comments in the code. They have X lines of code. I did a grep search and found a grand total of Y comment lines. For perspective our current code base has...







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 13 at 13:17









    Dark Matter Dark Matter

    4,74111021




    4,74111021








    • 3





      Point taken, though some people don't consider comment line % a great indicator of code quality :)

      – Gregory Currie
      Mar 13 at 13:19











    • @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

      – Dark Matter
      Mar 13 at 13:21








    • 3





      If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

      – Gregory Currie
      Mar 13 at 13:25






    • 1





      @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

      – Gregory Currie
      Mar 13 at 14:48








    • 3





      @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

      – jamesqf
      Mar 13 at 16:46














    • 3





      Point taken, though some people don't consider comment line % a great indicator of code quality :)

      – Gregory Currie
      Mar 13 at 13:19











    • @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

      – Dark Matter
      Mar 13 at 13:21








    • 3





      If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

      – Gregory Currie
      Mar 13 at 13:25






    • 1





      @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

      – Gregory Currie
      Mar 13 at 14:48








    • 3





      @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

      – jamesqf
      Mar 13 at 16:46








    3




    3





    Point taken, though some people don't consider comment line % a great indicator of code quality :)

    – Gregory Currie
    Mar 13 at 13:19





    Point taken, though some people don't consider comment line % a great indicator of code quality :)

    – Gregory Currie
    Mar 13 at 13:19













    @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

    – Dark Matter
    Mar 13 at 13:21







    @GregroyCurrie I took over a code base that had 100k+ lines of code which had a total of 7 comment lines. Those 7 lines of comments were worthless. There was no external documentation at all. He's got strong opinions, hopefully there are strong reasons.

    – Dark Matter
    Mar 13 at 13:21






    3




    3





    If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

    – Gregory Currie
    Mar 13 at 13:25





    If 7 lines of comments were worthless, couldn't 99k of comments be worthless :) I agree that good code has meaningful comments though.

    – Gregory Currie
    Mar 13 at 13:25




    1




    1





    @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

    – Gregory Currie
    Mar 13 at 14:48







    @TimB No argument from me. (Though some languages make it easier to write clear code, compared to others).

    – Gregory Currie
    Mar 13 at 14:48






    3




    3





    @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

    – jamesqf
    Mar 13 at 16:46





    @Dark Matter: On the other end of the scale, I've seen profusely commented code (often done with automatic "documentation" generators) in which the vast majority of comments are of the "i++; /* increment i */" sort.

    – jamesqf
    Mar 13 at 16:46











    5















    He invited me to this meeting, even though he had enough information from my preferences to know that I will likely strongly dislike the idea.




    Perhaps he is feeling pressured by his friends to put their software forward, even though he may not like it himself. He could be hoping that someone else will notice its flaws.



    I might talk to him directly (depending on our relationship) and try to determine what he really thinks. I would also try to point out the flaws in more neutral language than 'crap' software.






    share|improve this answer
























    • Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

      – Paul Johnson
      Mar 15 at 11:35
















    5















    He invited me to this meeting, even though he had enough information from my preferences to know that I will likely strongly dislike the idea.




    Perhaps he is feeling pressured by his friends to put their software forward, even though he may not like it himself. He could be hoping that someone else will notice its flaws.



    I might talk to him directly (depending on our relationship) and try to determine what he really thinks. I would also try to point out the flaws in more neutral language than 'crap' software.






    share|improve this answer
























    • Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

      – Paul Johnson
      Mar 15 at 11:35














    5












    5








    5








    He invited me to this meeting, even though he had enough information from my preferences to know that I will likely strongly dislike the idea.




    Perhaps he is feeling pressured by his friends to put their software forward, even though he may not like it himself. He could be hoping that someone else will notice its flaws.



    I might talk to him directly (depending on our relationship) and try to determine what he really thinks. I would also try to point out the flaws in more neutral language than 'crap' software.






    share|improve this answer














    He invited me to this meeting, even though he had enough information from my preferences to know that I will likely strongly dislike the idea.




    Perhaps he is feeling pressured by his friends to put their software forward, even though he may not like it himself. He could be hoping that someone else will notice its flaws.



    I might talk to him directly (depending on our relationship) and try to determine what he really thinks. I would also try to point out the flaws in more neutral language than 'crap' software.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 13 at 23:22









    paw88789paw88789

    1511




    1511













    • Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

      – Paul Johnson
      Mar 15 at 11:35



















    • Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

      – Paul Johnson
      Mar 15 at 11:35

















    Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

    – Paul Johnson
    Mar 15 at 11:35





    Very true. One of the best ways of saying "No" politely is to push the responsibility on to someone else.

    – Paul Johnson
    Mar 15 at 11:35











    3














    You call this software "crap" a couple of times, so you clearly know a thing or two about what it does, and what your company actually needs. Write up a document (email) outlining your concerns about the features / functionality, and send it to your boss.



    I would suggest also offering alternatives, such that you're not simply coming across as jealous, or negative. Make a table analyzing features, pricing, etc.




    Some options that don't share the same risks are X, and Y. The pricing for X is a little higher than the option proposed by John, but offers these advantages: ...




    At the very end of the email you may include a phrase along the lines of:




    As you can see, there are solid reasons why we should continue looking for a product to fill this niche. Furthermore I fear that John's decision to recommend this software may be influenced by the fact that a close personal friend of his created it.




    You may want to hold that tidbit of information in reserve just in case you have to escalate, however.






    share|improve this answer
























    • Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

      – Gray Sheep
      Mar 13 at 17:02


















    3














    You call this software "crap" a couple of times, so you clearly know a thing or two about what it does, and what your company actually needs. Write up a document (email) outlining your concerns about the features / functionality, and send it to your boss.



    I would suggest also offering alternatives, such that you're not simply coming across as jealous, or negative. Make a table analyzing features, pricing, etc.




    Some options that don't share the same risks are X, and Y. The pricing for X is a little higher than the option proposed by John, but offers these advantages: ...




    At the very end of the email you may include a phrase along the lines of:




    As you can see, there are solid reasons why we should continue looking for a product to fill this niche. Furthermore I fear that John's decision to recommend this software may be influenced by the fact that a close personal friend of his created it.




    You may want to hold that tidbit of information in reserve just in case you have to escalate, however.






    share|improve this answer
























    • Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

      – Gray Sheep
      Mar 13 at 17:02
















    3












    3








    3







    You call this software "crap" a couple of times, so you clearly know a thing or two about what it does, and what your company actually needs. Write up a document (email) outlining your concerns about the features / functionality, and send it to your boss.



    I would suggest also offering alternatives, such that you're not simply coming across as jealous, or negative. Make a table analyzing features, pricing, etc.




    Some options that don't share the same risks are X, and Y. The pricing for X is a little higher than the option proposed by John, but offers these advantages: ...




    At the very end of the email you may include a phrase along the lines of:




    As you can see, there are solid reasons why we should continue looking for a product to fill this niche. Furthermore I fear that John's decision to recommend this software may be influenced by the fact that a close personal friend of his created it.




    You may want to hold that tidbit of information in reserve just in case you have to escalate, however.






    share|improve this answer













    You call this software "crap" a couple of times, so you clearly know a thing or two about what it does, and what your company actually needs. Write up a document (email) outlining your concerns about the features / functionality, and send it to your boss.



    I would suggest also offering alternatives, such that you're not simply coming across as jealous, or negative. Make a table analyzing features, pricing, etc.




    Some options that don't share the same risks are X, and Y. The pricing for X is a little higher than the option proposed by John, but offers these advantages: ...




    At the very end of the email you may include a phrase along the lines of:




    As you can see, there are solid reasons why we should continue looking for a product to fill this niche. Furthermore I fear that John's decision to recommend this software may be influenced by the fact that a close personal friend of his created it.




    You may want to hold that tidbit of information in reserve just in case you have to escalate, however.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 13 at 13:14









    AndreiROMAndreiROM

    45.9k23108178




    45.9k23108178













    • Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

      – Gray Sheep
      Mar 13 at 17:02





















    • Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

      – Gray Sheep
      Mar 13 at 17:02



















    Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

    – Gray Sheep
    Mar 13 at 17:02







    Yes, I know far more enough from this software to call it a crap. Its only advantage is that it helps the developers to avoid learning technology X, what is a quite common technology in the industry, but somehow they've solved to avoid to learn it. Now the teamlead came with this software, which avoids them to learn it, as a side effect 1) it helps him to exterminate me 2) it will lead to malpractice on the long-term. I see these, but now the word of the teamlead + the developers standing with him is against mine. Surely mine will be more weak.

    – Gray Sheep
    Mar 13 at 17:02













    3














    Talk about it with your colleague/unofficial teamleader.



    You think he knows your opinion about the topic but it may not be this way.



    He invited you to the meeting which means he values your opinion. (I assume here that he didn't invite you to taunt you because your high opinion on the good working climate)



    Tell him directly that the software he wants to introduce would, in your opinion, hinder further development of the project.
    The cause for his support for the software in question might be personal, which he should overthink.
    If this isn't the case ask him to explain to you why he thinks the software will improve the development.



    A normal discussion about work related topic which does affect your work shouldn't cause danger to your employment or social status in your company.
    It might even improve because you show compassion for your work.



    But most importantly: You do it professional.



    EDIT1: If your colleague does not show any kind of good reasoning talk about it with your manager afterwards. Maybe propose a three-way discussion to get the topic dealt with fast.






    share|improve this answer





















    • 4





      He could also have been invited to give the illusion of objectivity.

      – Gregory Currie
      Mar 13 at 13:22






    • 2





      Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

      – GittingGud
      Mar 13 at 13:28






    • 1





      I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

      – Gregory Currie
      Mar 13 at 13:31
















    3














    Talk about it with your colleague/unofficial teamleader.



    You think he knows your opinion about the topic but it may not be this way.



    He invited you to the meeting which means he values your opinion. (I assume here that he didn't invite you to taunt you because your high opinion on the good working climate)



    Tell him directly that the software he wants to introduce would, in your opinion, hinder further development of the project.
    The cause for his support for the software in question might be personal, which he should overthink.
    If this isn't the case ask him to explain to you why he thinks the software will improve the development.



    A normal discussion about work related topic which does affect your work shouldn't cause danger to your employment or social status in your company.
    It might even improve because you show compassion for your work.



    But most importantly: You do it professional.



    EDIT1: If your colleague does not show any kind of good reasoning talk about it with your manager afterwards. Maybe propose a three-way discussion to get the topic dealt with fast.






    share|improve this answer





















    • 4





      He could also have been invited to give the illusion of objectivity.

      – Gregory Currie
      Mar 13 at 13:22






    • 2





      Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

      – GittingGud
      Mar 13 at 13:28






    • 1





      I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

      – Gregory Currie
      Mar 13 at 13:31














    3












    3








    3







    Talk about it with your colleague/unofficial teamleader.



    You think he knows your opinion about the topic but it may not be this way.



    He invited you to the meeting which means he values your opinion. (I assume here that he didn't invite you to taunt you because your high opinion on the good working climate)



    Tell him directly that the software he wants to introduce would, in your opinion, hinder further development of the project.
    The cause for his support for the software in question might be personal, which he should overthink.
    If this isn't the case ask him to explain to you why he thinks the software will improve the development.



    A normal discussion about work related topic which does affect your work shouldn't cause danger to your employment or social status in your company.
    It might even improve because you show compassion for your work.



    But most importantly: You do it professional.



    EDIT1: If your colleague does not show any kind of good reasoning talk about it with your manager afterwards. Maybe propose a three-way discussion to get the topic dealt with fast.






    share|improve this answer















    Talk about it with your colleague/unofficial teamleader.



    You think he knows your opinion about the topic but it may not be this way.



    He invited you to the meeting which means he values your opinion. (I assume here that he didn't invite you to taunt you because your high opinion on the good working climate)



    Tell him directly that the software he wants to introduce would, in your opinion, hinder further development of the project.
    The cause for his support for the software in question might be personal, which he should overthink.
    If this isn't the case ask him to explain to you why he thinks the software will improve the development.



    A normal discussion about work related topic which does affect your work shouldn't cause danger to your employment or social status in your company.
    It might even improve because you show compassion for your work.



    But most importantly: You do it professional.



    EDIT1: If your colleague does not show any kind of good reasoning talk about it with your manager afterwards. Maybe propose a three-way discussion to get the topic dealt with fast.







    share|improve this answer














    share|improve this answer



    share|improve this answer








    edited Mar 13 at 13:24

























    answered Mar 13 at 13:19









    GittingGudGittingGud

    44618




    44618








    • 4





      He could also have been invited to give the illusion of objectivity.

      – Gregory Currie
      Mar 13 at 13:22






    • 2





      Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

      – GittingGud
      Mar 13 at 13:28






    • 1





      I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

      – Gregory Currie
      Mar 13 at 13:31














    • 4





      He could also have been invited to give the illusion of objectivity.

      – Gregory Currie
      Mar 13 at 13:22






    • 2





      Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

      – GittingGud
      Mar 13 at 13:28






    • 1





      I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

      – Gregory Currie
      Mar 13 at 13:31








    4




    4





    He could also have been invited to give the illusion of objectivity.

    – Gregory Currie
    Mar 13 at 13:22





    He could also have been invited to give the illusion of objectivity.

    – Gregory Currie
    Mar 13 at 13:22




    2




    2





    Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

    – GittingGud
    Mar 13 at 13:28





    Nevertheless the fact that OP was invited to the meeting means that the OP does have competence in the topic and is therefore qualified/entitled to be part of the decision. And because the co-worker cannot end the illusion now means that he can do nothing about OP expressing his honest and professional opinion.

    – GittingGud
    Mar 13 at 13:28




    1




    1





    I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

    – Gregory Currie
    Mar 13 at 13:31





    I don't think that's necessarily true, though it is probably true in this instance. But I agree fully that he should make the most of this "illusion".

    – Gregory Currie
    Mar 13 at 13:31











    3














    Your colleague has a conflict of interest. You should discuss this with the other members of your organization, and make sure that the software is properly evaluated by a party without vested interest and free from undue influence.






    share|improve this answer
























    • A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

      – Gray Sheep
      Mar 13 at 18:02
















    3














    Your colleague has a conflict of interest. You should discuss this with the other members of your organization, and make sure that the software is properly evaluated by a party without vested interest and free from undue influence.






    share|improve this answer
























    • A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

      – Gray Sheep
      Mar 13 at 18:02














    3












    3








    3







    Your colleague has a conflict of interest. You should discuss this with the other members of your organization, and make sure that the software is properly evaluated by a party without vested interest and free from undue influence.






    share|improve this answer













    Your colleague has a conflict of interest. You should discuss this with the other members of your organization, and make sure that the software is properly evaluated by a party without vested interest and free from undue influence.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 13 at 15:53









    MattHMattH

    792




    792













    • A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

      – Gray Sheep
      Mar 13 at 18:02



















    • A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

      – Gray Sheep
      Mar 13 at 18:02

















    A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

    – Gray Sheep
    Mar 13 at 18:02





    A possible conflict of interest is a non-issue if the tool is good, and this is what now the whole team except me is saying.

    – Gray Sheep
    Mar 13 at 18:02











    2














    If his friend doesn't work for the company, then injecting his buds software into the company's workflow is simply a conflict of interest. Pointing that out would help a lot.



    I'd also explain to my boss why this software is crap and I'd try to provide some cost benefits analysis of using it. I'd even go so far as to attempt to show how much money the company will lose from the lost development time dealing with the unmaintainable can of worms your team lead's friend is trying to pass off as code. That should help too.



    You are going above your team leads head though, so this likely won't have the greatest impact on your career at your current company. You're a dev though; you can always get another job, that will probably come with a pay raise, so you shouldn't be scared in situations like these.






    share|improve this answer
























    • I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

      – Gray Sheep
      Mar 13 at 16:53













    • Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

      – Gray Sheep
      Mar 13 at 17:15








    • 1





      @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

      – Steve
      Mar 13 at 17:19






    • 2





      Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

      – Gray Sheep
      Mar 13 at 18:01






    • 1





      @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

      – Steve
      Mar 14 at 15:22
















    2














    If his friend doesn't work for the company, then injecting his buds software into the company's workflow is simply a conflict of interest. Pointing that out would help a lot.



    I'd also explain to my boss why this software is crap and I'd try to provide some cost benefits analysis of using it. I'd even go so far as to attempt to show how much money the company will lose from the lost development time dealing with the unmaintainable can of worms your team lead's friend is trying to pass off as code. That should help too.



    You are going above your team leads head though, so this likely won't have the greatest impact on your career at your current company. You're a dev though; you can always get another job, that will probably come with a pay raise, so you shouldn't be scared in situations like these.






    share|improve this answer
























    • I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

      – Gray Sheep
      Mar 13 at 16:53













    • Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

      – Gray Sheep
      Mar 13 at 17:15








    • 1





      @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

      – Steve
      Mar 13 at 17:19






    • 2





      Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

      – Gray Sheep
      Mar 13 at 18:01






    • 1





      @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

      – Steve
      Mar 14 at 15:22














    2












    2








    2







    If his friend doesn't work for the company, then injecting his buds software into the company's workflow is simply a conflict of interest. Pointing that out would help a lot.



    I'd also explain to my boss why this software is crap and I'd try to provide some cost benefits analysis of using it. I'd even go so far as to attempt to show how much money the company will lose from the lost development time dealing with the unmaintainable can of worms your team lead's friend is trying to pass off as code. That should help too.



    You are going above your team leads head though, so this likely won't have the greatest impact on your career at your current company. You're a dev though; you can always get another job, that will probably come with a pay raise, so you shouldn't be scared in situations like these.






    share|improve this answer













    If his friend doesn't work for the company, then injecting his buds software into the company's workflow is simply a conflict of interest. Pointing that out would help a lot.



    I'd also explain to my boss why this software is crap and I'd try to provide some cost benefits analysis of using it. I'd even go so far as to attempt to show how much money the company will lose from the lost development time dealing with the unmaintainable can of worms your team lead's friend is trying to pass off as code. That should help too.



    You are going above your team leads head though, so this likely won't have the greatest impact on your career at your current company. You're a dev though; you can always get another job, that will probably come with a pay raise, so you shouldn't be scared in situations like these.







    share|improve this answer












    share|improve this answer



    share|improve this answer










    answered Mar 13 at 16:22









    SteveSteve

    3,102618




    3,102618













    • I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

      – Gray Sheep
      Mar 13 at 16:53













    • Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

      – Gray Sheep
      Mar 13 at 17:15








    • 1





      @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

      – Steve
      Mar 13 at 17:19






    • 2





      Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

      – Gray Sheep
      Mar 13 at 18:01






    • 1





      @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

      – Steve
      Mar 14 at 15:22



















    • I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

      – Gray Sheep
      Mar 13 at 16:53













    • Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

      – Gray Sheep
      Mar 13 at 17:15








    • 1





      @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

      – Steve
      Mar 13 at 17:19






    • 2





      Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

      – Gray Sheep
      Mar 13 at 18:01






    • 1





      @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

      – Steve
      Mar 14 at 15:22

















    I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

    – Gray Sheep
    Mar 13 at 16:53







    I am here because the athmosphere is nice and the bosses hear us. These are huge improvements to my previous experiences, and they worth the little bit lower wage for me. I don't want to become a slave again only for +10%. If I switch to another job, I will lose these.

    – Gray Sheep
    Mar 13 at 16:53















    Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

    – Gray Sheep
    Mar 13 at 17:15







    Ok. There is a technology, call "technology X", which is quite common in the industry and practically all useful developer knows it. Our devs somehow managed to avoid to learn it until now. The tool, call it "tool Y" what the teamlead want to inject, has three effects: 1) avoids the devs to learn "technology X" 2) will lead to various malpractices/customer unsatisifedness on the long-term 3) expels me as devops from the projects using "technology X". | These are the facts. What are the motives, these are still unknown for me.

    – Gray Sheep
    Mar 13 at 17:15






    1




    1





    @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

    – Steve
    Mar 13 at 17:19





    @GraySheep why is your involvement with the project pivotal to its success? What other advantages would learning tech X give your team. You need an estimate of how much time/money the malpractices will cause. Also, is there a good reason that your team insists on not using tech X?

    – Steve
    Mar 13 at 17:19




    2




    2





    Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

    – Gray Sheep
    Mar 13 at 18:01





    Regarding your answer: I can't point to the conflict of interest because I am 99% sure, but I have no proof. I won't accuse anybody falsely. And the final decision is not in the hands of the teamlead, but in the hands of the boss. I explained these in a mail, so professionally as I could. My word will be probably far weaker than the whole teams.

    – Gray Sheep
    Mar 13 at 18:01




    1




    1





    @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

    – Steve
    Mar 14 at 15:22





    @GraySheep You must be in London. Be careful about the freelancer stuff. You can make double, but you also need to pay for all of your stuff, healthcare, taxes, etc...

    – Steve
    Mar 14 at 15:22











    1














    make questions.



    identify some issue that will arise using that software and ask how it will be handled.




    we support multiple platforms but this tool does not: how this will be handled? we're leaving development on platform X that's the core of our customer base?



    this new tool is licensed under license X that is not compatible with our product: a rewrite of our license may be required?



    we're automating task X, Y and Z with a cut to the costs of 15% but this new tool is not compatible with current automation software: which automation solution we have to acquire to achieve the same goal?




    management pay attention to costs but usually does not care about technicalities; if you can provide a few heavy questions with visible costs attached your point can get across easily.



    make too many or too silly/whyning questions and you will lose any traction from now on and will be labeled as troublemaker.






    share|improve this answer




























      1














      make questions.



      identify some issue that will arise using that software and ask how it will be handled.




      we support multiple platforms but this tool does not: how this will be handled? we're leaving development on platform X that's the core of our customer base?



      this new tool is licensed under license X that is not compatible with our product: a rewrite of our license may be required?



      we're automating task X, Y and Z with a cut to the costs of 15% but this new tool is not compatible with current automation software: which automation solution we have to acquire to achieve the same goal?




      management pay attention to costs but usually does not care about technicalities; if you can provide a few heavy questions with visible costs attached your point can get across easily.



      make too many or too silly/whyning questions and you will lose any traction from now on and will be labeled as troublemaker.






      share|improve this answer


























        1












        1








        1







        make questions.



        identify some issue that will arise using that software and ask how it will be handled.




        we support multiple platforms but this tool does not: how this will be handled? we're leaving development on platform X that's the core of our customer base?



        this new tool is licensed under license X that is not compatible with our product: a rewrite of our license may be required?



        we're automating task X, Y and Z with a cut to the costs of 15% but this new tool is not compatible with current automation software: which automation solution we have to acquire to achieve the same goal?




        management pay attention to costs but usually does not care about technicalities; if you can provide a few heavy questions with visible costs attached your point can get across easily.



        make too many or too silly/whyning questions and you will lose any traction from now on and will be labeled as troublemaker.






        share|improve this answer













        make questions.



        identify some issue that will arise using that software and ask how it will be handled.




        we support multiple platforms but this tool does not: how this will be handled? we're leaving development on platform X that's the core of our customer base?



        this new tool is licensed under license X that is not compatible with our product: a rewrite of our license may be required?



        we're automating task X, Y and Z with a cut to the costs of 15% but this new tool is not compatible with current automation software: which automation solution we have to acquire to achieve the same goal?




        management pay attention to costs but usually does not care about technicalities; if you can provide a few heavy questions with visible costs attached your point can get across easily.



        make too many or too silly/whyning questions and you will lose any traction from now on and will be labeled as troublemaker.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered Mar 13 at 21:32









        PaoloPaolo

        1,5701512




        1,5701512























            0














            You mention this software being awful, crap as you call it.



            Prove it!



            Crap software is:




            • very unstable (what if you let it run with a lot of requests at the same time) => perform load tests

            • very picky on input data/parameters (when you enter a string where a number is expected, the whole thing crashes).

            • from a developer point of view, very heavily maintainable : imagine that somebody requests a change, how many time is needed for developing an obvious modification?

            • not user friendly (how should it look like?)

            • wasting resources (how long does it take for making the easiest of calculations, how many memory does it use up, ...?)


            I understand: setting up an environment for proving the bad quality of this software might take some time, so in order to convince management, you might inform management about your doubts and request for some time to prepare the testing environment (in case this is not available yet).






            share|improve this answer


























            • This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

              – Gray Sheep
              Mar 15 at 9:47
















            0














            You mention this software being awful, crap as you call it.



            Prove it!



            Crap software is:




            • very unstable (what if you let it run with a lot of requests at the same time) => perform load tests

            • very picky on input data/parameters (when you enter a string where a number is expected, the whole thing crashes).

            • from a developer point of view, very heavily maintainable : imagine that somebody requests a change, how many time is needed for developing an obvious modification?

            • not user friendly (how should it look like?)

            • wasting resources (how long does it take for making the easiest of calculations, how many memory does it use up, ...?)


            I understand: setting up an environment for proving the bad quality of this software might take some time, so in order to convince management, you might inform management about your doubts and request for some time to prepare the testing environment (in case this is not available yet).






            share|improve this answer


























            • This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

              – Gray Sheep
              Mar 15 at 9:47














            0












            0








            0







            You mention this software being awful, crap as you call it.



            Prove it!



            Crap software is:




            • very unstable (what if you let it run with a lot of requests at the same time) => perform load tests

            • very picky on input data/parameters (when you enter a string where a number is expected, the whole thing crashes).

            • from a developer point of view, very heavily maintainable : imagine that somebody requests a change, how many time is needed for developing an obvious modification?

            • not user friendly (how should it look like?)

            • wasting resources (how long does it take for making the easiest of calculations, how many memory does it use up, ...?)


            I understand: setting up an environment for proving the bad quality of this software might take some time, so in order to convince management, you might inform management about your doubts and request for some time to prepare the testing environment (in case this is not available yet).






            share|improve this answer















            You mention this software being awful, crap as you call it.



            Prove it!



            Crap software is:




            • very unstable (what if you let it run with a lot of requests at the same time) => perform load tests

            • very picky on input data/parameters (when you enter a string where a number is expected, the whole thing crashes).

            • from a developer point of view, very heavily maintainable : imagine that somebody requests a change, how many time is needed for developing an obvious modification?

            • not user friendly (how should it look like?)

            • wasting resources (how long does it take for making the easiest of calculations, how many memory does it use up, ...?)


            I understand: setting up an environment for proving the bad quality of this software might take some time, so in order to convince management, you might inform management about your doubts and request for some time to prepare the testing environment (in case this is not available yet).







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Mar 14 at 20:39

























            answered Mar 14 at 20:31









            DominiqueDominique

            1,310315




            1,310315













            • This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

              – Gray Sheep
              Mar 15 at 9:47



















            • This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

              – Gray Sheep
              Mar 15 at 9:47

















            This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

            – Gray Sheep
            Mar 15 at 9:47





            This is what I did. I've proven it. Unfortunately, my arguments were probably not enough convincing in these circumstances, but this was the most I could do.

            – Gray Sheep
            Mar 15 at 9:47





            protected by Mister Positive Mar 14 at 0:04



            Thank you for your interest in this question.
            Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).



            Would you like to answer one of these unanswered questions instead?



            Popular posts from this blog

            Masuk log Menu navigasi

            Identifying “long and narrow” polygons in with PostGISlength and width of polygonWhy postgis st_overlaps reports Qgis' “avoid intersections” generated polygon as overlapping with others?Adjusting polygons to boundary and filling holesDrawing polygons with fixed area?How to remove spikes in Polygons with PostGISDeleting sliver polygons after difference operation in QGIS?Snapping boundaries in PostGISSplit polygon into parts adding attributes based on underlying polygon in QGISSplitting overlap between polygons and assign to nearest polygon using PostGIS?Expanding polygons and clipping at midpoint?Removing Intersection of Buffers in Same Layers

            Старые Смолеговицы Содержание История | География | Демография | Достопримечательности | Примечания | НавигацияHGЯOLHGЯOL41 206 832 01641 606 406 141Административно-территориальное деление Ленинградской области«Переписная оброчная книга Водской пятины 1500 года», С. 793«Карта Ингерманландии: Ивангорода, Яма, Копорья, Нотеборга», по материалам 1676 г.«Генеральная карта провинции Ингерманландии» Э. Белинга и А. Андерсина, 1704 г., составлена по материалам 1678 г.«Географический чертёж над Ижорскою землей со своими городами» Адриана Шонбека 1705 г.Новая и достоверная всей Ингерманландии ланткарта. Грав. А. Ростовцев. СПб., 1727 г.Топографическая карта Санкт-Петербургской губернии. 5-и верстка. Шуберт. 1834 г.Описание Санкт-Петербургской губернии по уездам и станамСпецкарта западной части России Ф. Ф. Шуберта. 1844 г.Алфавитный список селений по уездам и станам С.-Петербургской губернииСписки населённых мест Российской Империи, составленные и издаваемые центральным статистическим комитетом министерства внутренних дел. XXXVII. Санкт-Петербургская губерния. По состоянию на 1862 год. СПб. 1864. С. 203Материалы по статистике народного хозяйства в С.-Петербургской губернии. Вып. IX. Частновладельческое хозяйство в Ямбургском уезде. СПб, 1888, С. 146, С. 2, 7, 54Положение о гербе муниципального образования Курское сельское поселениеСправочник истории административно-территориального деления Ленинградской области.Топографическая карта Ленинградской области, квадрат О-35-23-В (Хотыницы), 1930 г.АрхивированоАдминистративно-территориальное деление Ленинградской области. — Л., 1933, С. 27, 198АрхивированоАдминистративно-экономический справочник по Ленинградской области. — Л., 1936, с. 219АрхивированоАдминистративно-территориальное деление Ленинградской области. — Л., 1966, с. 175АрхивированоАдминистративно-территориальное деление Ленинградской области. — Лениздат, 1973, С. 180АрхивированоАдминистративно-территориальное деление Ленинградской области. — Лениздат, 1990, ISBN 5-289-00612-5, С. 38АрхивированоАдминистративно-территориальное деление Ленинградской области. — СПб., 2007, с. 60АрхивированоКоряков Юрий База данных «Этно-языковой состав населённых пунктов России». Ленинградская область.Административно-территориальное деление Ленинградской области. — СПб, 1997, ISBN 5-86153-055-6, С. 41АрхивированоКультовый комплекс Старые Смолеговицы // Электронная энциклопедия ЭрмитажаПроблемы выявления, изучения и сохранения культовых комплексов с каменными крестами: по материалам работ 2016-2017 гг. в Ленинградской области