Pressure from supervisor to use the software he is developing

Question

I am currently a PhD student in a computational lab. My supervisor manages a program that is relevant to our field and which is supposed to be better and faster. Our group is mainly focused on application. (No PhD students are here to code. There was one but they left.) Personally, my research project focuses on using "new tools", the software is vaguely mentioned, but it is not the main focus.

I tried to use this software, but after nearly one year of testing, the conclusion is clear: it is not adapted for my project.

My supervisor does not accept that. When I explain the problems to him, I basically get a long monologue of why this is normal, and that research takes time. Also, sometimes he asks me to fix the code myself.

Because I am worried about the quality of my PhD, I started to do work on my own with another open-source software. I got interesting results which I started to write about. He now wants to introduce his software in the paper, basically changing the entire story.

Unfortunately, he seems to be a better diplomat than a scientist, and it is really hard to discuss with him.

Now the question: If I work in a group which develops and represents software X, can I publish without using this software (if the paper could be done using it, naturally)?

Answer 1

If you are sole author of a paper, then yes, you can organize it as you wish and use tools you feel appropriate. If you have co-authors then you need to agree.

But the other, unasked, question is whether it is wise to ignore a supervisor who has some influence over your future, both for finishing and thereafter. It is a question of finesse that you need to work out.

One thing your supervisor is correct about, is that things take time. But he should not make you suffer for the time it takes to improve his software.

I do suggest that you try to help him as much as reasonable with developing the software, and you may be in a good position to do so if you have alternate (and better) results with other software. If he is wise (perhaps questionable), then he should welcome that.

But, look to your own interests. You need to finish and develop your career. Outright refusal to work with him on this will probably be a negative.

Answer 2

For better or worse, the advisor might consider the software they co-developed as a significant part of their research group's output. In that context, it is entirely plausible to them that PhD students use this program, and -- as part of their work -- help improving it. Having a student just dabble with other software is unlikely to result in a thesis that fits the experience and interests of the adviser.

One possible route could be to understand how/why the other software is better and to see how one could use this to improve the software developed by the lab.

If you feel strongly that you simply want to use other software, this research group is likely not be a good fit for you.

Answer 3

Your main focus should be on getting results. If tool A can help you get results that you can’t get using tool B, then there is no question that the scientifically correct thing to do is to use tool A. It is literally your duty as a scientist to use the tool that you think is the correct one that’s adapted to your project and that will maximize the scientific value of your work. To bend to your advisor’s will on this seems to largely defeat the purpose of doing a PhD in the first place. Even if it leads you to a marginally more successful academic career, it will turn you into a cynical academic who believes that everything academics do is motivated by self-interest and pandering to people in positions of power rather than a desire to do good science.

However, it is also the case that…

a legitimate secondary goal is to keep your advisor happy. We live in the real world, not a Socratic utopia. In the real world, you are doing your work within the confines of academia, where it is expected that you will not just pursue scientific Truth but also show the ability to work as part of a team, and the humility and tact to defer to the wisdom and experience of your superiors (even on some occasions when they may not be quite as wise as they think they are).

The conclusion is that, in pursuit of this secondary goal, it would not be a betrayal of your principles to spend at least a modest amount of time doing things your advisor wants you to do even if you don’t want to do them or they seem pointless.^* So I’d suggest that, in addition to using the scientifically correct tool you’ve identified, you also learn to work with your advisor’s software and try to incorporate some use of it into your thesis and/or papers, to the extent that that can be justified as supporting the science you are doing, even if only marginally so.

^{* Assuming your advisor isn’t asking you to do something that’s outright fraudulent or crackpotty, that is.}

Finally, keep in mind that…

another legitimate secondary goal of a PhD is to learn useful skills. You may not think that your PhD should involve coding, but if you look at it a different way, your advisor is actually giving you a valuable opportunity to acquire some extremely useful and marketable coding skills. When I meet people from industry they tell me things like that software engineers are so much in demand these days that they “can write their own paychecks” (literally a phrase I heard from a senior HR manager at a large Silicon Valley company). So don’t underestimate the value of acquiring coding skills even if they don’t have a direct relevance to (your own personal vision of) what your PhD is about, or if acquiring these skills requires you to get out of your comfort zone. Indeed, it is precisely the things that take us out of our comfort zones that help us develop and grow as academics, researchers, or future [fill in the blank]’s.

Answer 4

As someone who has seen this arrangement (although with less pushy supervisors) from multiple points of view... Yes, you are not obliged to use the software. Go and publish on your own, learn to be an independent researcher!

That is not to say you have to be at odds with your supervisor about this issue should you choose to use something else. You say he is a good diplomat - learn from that! One example of good diplomacy would be getting a carte blanche for using any other software tools for your project by explaining how it would help developing his own software. Be more detailed and helpful with your feedback: if open-source project X worked but not your lab's own thing, why is that? What were the main obstacles and how could you or him improve on that? Could you directly borrow from these external projects?

I would give you a cautionary tale, however. Having a holistic vision about the product is important. I have been working for about 5 years on a project (product A) which was meant to be a modern replacement for the industry standard thing going for upwards of $2000 per license. We have replicated the entire core functionality and added a couple of features of our own. The problem? No one has an idea of how to market it and the entirety of the development team was pretty much uninterested in doing so. It is used as a free alternative in courses in a couple of affiliated universities and that is it. Now the team has fallen apart and one of the members is working on what he deems a better UX replacement for the product A. It does have some nice touches, but is a huge mess architecturally and massively lacking features compared to the old one: I would expect it to grind to a complete halt in some 3-5 years if he decides to follow this path. But it got a lot more traction because he now has a vision of the product and pitches it more actively to prospective users.

The moral of the story? You might get good results, but they will be buried and forgotten unless they are either absolutely outstanding - which many of us not-so-secretly wish for - or you "sell" them well. Until you convince your supervisor of the value of your work, they will be a hindrance instead of helping you to realize your potential. Turning your assets into liabilities is one easy way to get nowhere at all.

Answer 5

You might want to try to understand why your supervisor prefers that you use his code. Is it because developing this code is part of the grant you're funded from (as mentioned in another answer)? One reason that hasn't been mentioned yet is:

It's much easier for your supervisor to check the correctness of your work (configuration files, etc) if you use software that they're familiar with.

One reason that the supervisor might prefer that you use his software is that he understands it well and can therefore adequately check the correctness of your methodology. A PI is often held responsible for the research that comes out of their lab (especially if they are funding you through a grant) and it is also their responsibility to train in you correct practices. It might be difficult for them to do this if you are using software that they are not familiar with.

I don't require my students to use only software that I'm familiar with, but I strongly suggest it, since I can provide them with help and examples of working configurations. In some cases, they have wanted to use different codes and I have allowed it with sufficient justification (the code they want to use has features the code I use doesn't have). In these cases, I ask them to explain to me how the code works and sometimes I read the documentation to ensure what they are doing is correct. Beginning students sometimes don't have as good of an understanding of what can go wrong with calculations as I do and I am better able to spot problems even if I don't know the software well. Honestly, I don't always trust my beginning students to set up the calculations correctly because there are so many ways to make mistakes. This is my job as their supervisor.

One idea to get your supervisor to accept you using the new code might be to run some test cases (maybe simple toy models) demonstrating that the software you are using provides similar results to his software. You could also show what is hard to do with his software that you'd like to do, but is easier to do with the software you found.

Answer 6

There a are two questions:

1. Regarding your paper:
   You should stick to the facts which software was used to produce the results. You can explain that both would lead to the same result and explain different approaches, run-times etc. If the results are different, you can discuss these differences. You also can mention the software from your advisor in the introduction as similar products. But you should not stretch the truth - for whatever reason.
2. Regarding your PhD thesis:
   With the given situation, I don't think you will graduate under your advisor with a different software then the one he develops. Either you find another advisor or figure a way to get used to it and the way your advisor works. Talk to other lab members how they handle the situation. Probably you are going to suffer. Decide whether it is better to through away your last year of work and find a new advisor, or stick for the upcoming years with an advisor you have difficulties to work with.