Supervisor wants me to support a diploma-thesis software tool after I graduated

Question

During my last year of MSc. studies, I was part-time employed on the university project. The project was related to my diploma thesis, and my task was to create a data-mining software and run experiments using this software.

I've finished the software, run the experiments in it, successfully graduated, and finished the studies. It was a huge success for me and for the university as the diploma thesis was awarded in a student's competitions, being top 10 among 2000 diploma theses.

Despite this success, the software I developed is not production-ready, rather just a prototype. For my experiments I considered only happy-case scenarios and if there are some unexpected inputs from the user/from connected systems/uploaded CSV files do not match specification, etc., the software crashes and cannot be used.

My supervisor wants to use the software usually twice a year. When he runs into some troubles with it, he emails me to deploy fixes so that he can run the experiments. In the first year and a half after I finished the project and the software, I did it three times. Now he is asking again to debug the problems in the software and fix them. I do not want to do it, because:

1. I have no time for it because of very time-consuming projects in my current job.
2. I am working in a different industry now and during two years I forgot many things from the software development and specific solutions I used.
3. I already lost accesses to the production environment at the university, so I am not able to deploy fixes.
4. I feel stressed out by the requests. As this was a prototype I did not set up logging, and I usually struggle to find and fix the error cause. I sometimes even cannot reproduce the errors locally and then I really do not know how to fix it.

I wrote these reasons to him, but he insists that I should still help them with it. He offered me they will pay me again some hour rate to support the software, get production accesses again, etc. But the money is no matter for me; I just do not want to continue with supporting the tool.

I feel there was some misunderstanding from their side about what are difference between diploma-thesis prototype and production-ready software. We never agreed officially that I would support it. We just once talked about that I would support it "for some time if some problems occurs", which I believe I did (three bugfixes and approximately three months of work during a year and a half after I graduated).

Is there a way how to politely refuse while still keeping good relationship with the supervisor as he is always very nice and polite?

I was thinking to offer him a one- or two-day workshop for some of the current university employees where we could go through the code on GitHub, and I would officially hand it over to the current employee. But it would not be a solution for him, as there are only a handful of postgraduate students in their group, and they are not programmers, so they cannot take the software over.

And I feel bad about writing to him: “I do not have a solution, I do not want to continue with that, and I do not care that you cannot use the software any more...”

Answer 1

I have mixed feelings about this question, and I wanted to write an answer simply because it would be too long for a comment.

While I agree with the general sentiment that if this was asked on workplace stackexchange the typical advice would be that you do not owe him such service, I also understand that academia is a very different context, where programming is often a side-effect of the research rather than the 'main product' as it were.

The problem with this, as you're coming to realise, is that there is a lot of 'bad code' in academia. And one needs to clarify what 'bad code' means here: it does not mean that it does not do well what it was designed to do. It means that it is devoid of any of the software engineering good practices that typically make code flexible, maintainable, supported by tests covering specification and edge-cases, versioning, documentation, etc. In other words, what you call "production-ready".

There are good and bad reasons for such "bad code" in academia, but at the end of the day, the fact is that the code is bad by design. You decided it was meant to be prototype code rather than production-ready, and accepted that risk given your use-context and intent at the time. In that, your code was designed to not be maintainable, supported by tests, documentation, etc, because you had a very particular problem in mind to solve which you felt did not require or justify these features for the allocated time. I have mixed feelings about this because, as you're coming to realise, typically this is technical-debt that tends to catch up with you exponentially, but, it is what it is, what's done is done, and that's what you need to deal with now.

Therefore the crucial difference here, is that when your supervisor talks about 'bugfixes', these are not actually bugfixes as such. They are "features". He is in fact asking you to add functionality and extra work that was not part of the original intent and "design". He is effectively asking you to do new work (and boring one at that), that you have neither interest in, nor pays market rates (even if you cared to do it). The fact that this work is tangentially related to something you've worked on the past has no bearing on anything.

Your supervisor, especially if he's not programming-savvy, may not understand this crucial difference (or in the words of Upton Sinclair, it may be impossible to make him understand it, if his work depends on him not understanding it). But, however you decide to tackle this issue, part of your reply to him must make this point clear: that what he's asking you to do is, to use a car analogy, a lot less like performing trivial standard maintenance* (e.g. doing an oil change), and a lot like him expecting your machine to act like a proper general-purpose car, when it was only supposed to serve a single route, for a single individual, on a particular day. You need to impress on him that if your supervisor wants to make 12 trips in this 'car', it's not a case that if a route has problems you'll make some small adjustment for him, you're literally gonna have to design 12 routes for him, each one from scratch, because that 'car' was never supposed to be able to go on a general route to begin with, nor is it the right kind of machine for that task.

And if what he wants is a general purpose, production-ready car, really the only viable, long-term solution is for him to get (i.e. pay) someone (i.e. a professional) to build it for him.

---

_{* and even if it were, it would still be inappropriate for him to be asking you to commit to such maintenance for life anyway, however trivial.}

Answer 2

I think you are being generous and, given what you say, should be able to step away from the project with a clear conscience.

If he needs the software he should be willing to find a way to pay for support, maybe not you, I think, but some support person.

I would see him if possible or send an email giving much of the information you've given here. The fact that you are doing very different things now and that support is disruptive to your main goals should be definitive.

But I agree that it is good to find a way to keep a good relationship with him if you can also achieve your main goal.

Answer 3

He has had your work for free 3 times already.

If he was serious he would have offered some reward the first time...

Unless you get him to commit to paying upfront, then he won't pay. He should have continued the project with other students since you left but did not, I suggest he won't be able to fund you for your continued work or other students as he cannot get any more funding for that project.

Get out and stay out is my 2 pence worth...

Answer 4

The typical answer over on Workplace.SE would be to say "I'll do it if you pay me X" or "I can only do it if you pay me X". You pick X high enough that you don't think they'll accept (shouldn't be too hard in academia) and high enough that you'd actually be happy to do the work in case they actually do accept it. Unless you actively want to do the work, the amount should at a minimum match what you'd get by spending the same time on your actual job.

It's possible that this will make the professor angry and impair your relationship. However, based on what you write, why do you need to keep him happy? You're in industry now, and what you describe sounds like a very one-sided relationship - you do work, and at best you'd be offered to be paid a small amount. (Or so I assume - academic salaries are typically a bit lower.)

Answer 5

Generally speaking, I agree with Tasos's answer. But I'd like to emphasize the long-term aspects of your response. Are you still in academia? If you are, or even if you are not, it'd be beneficial for you to make sure that you maintain a good relationship with your former advisor. And to ensure the long-term life of something which you yourself describe as 'a huge success'. Rather than keep it as a vanishing line on your resume, ensuring that this becomes a useful tool that's recognized as such and widely used can only be good for your career in the long term.

So sit down with your advisor and have a talk with them about how this tool can become more generally useful. It's already in a github repository? Great. Is it public? Before you talk to your advisor, and before you do any actual further work, how about making it more ready for prime time?

Can you take some time and improve the github presentation? First, make a list of what would need to happen to make it more viable, maybe making them formal issues. Can you explain better how it works up front, throw in some comments about assumptions, reasons to do things one way or another? Can you throw in at least an example of what format(s) you expect the inputs to look like?

Then try to negotiate not doing any actual fix yourself, but helping someone else do them, filling in the doc as needed. If you need access to the university's production environment to simplify the task, I'm sure your advisor can arrange that with the IT department. And you have a whole university to work with, a listing in the job center should scare up at least a student to take up the project. If you can find an actual staff member to help, you'd be better off, as your training would be more useful in the long term. But even a student would do, as it'd force you to be more explicit in comments/documentation.

In any case, finding a successor should be your advisor's problem, not yours. You should limit yourself to vetting and training the successor, and that is already being a very good software owner.

Answer 6

Check your employment contract. Often, if you're working in IT, there will be terms that state that your employer owns all software you produce while working for them - which would also include all new features you produce for this previous software, even if you're working on it in your spare time. If you have such a term in your contract, you can simply tell your previous professor that unless he is willing to allow your employer to take ownership of the software and pay them a licensing fee, you will be unable to continue working on the software.

Answer 7

It is my subjective opinion. If I were you I would be glad that someone is interested in and actually using my work. I don't know about other people but I find such events rare in my life. Everyone is just interested in themselves.

Answer 8

If your current company does any kind of development that is sold to clients, I would see if your company could provide him such service.

You mention that you are now in different industry, but even though it would be a peculiar decision to hire a company that made microcontrollers for waste collection systems that have nothing to do with data-mining software:

• The supervisor would probably be happy to choose that company, as long as you were there
• Your company would be happy to sell a product to a new client, as long as he pays adequately for that.

if that worked out, and you were assigned to this, you would have to be freed from (some of) your current time-consuming projects, and you would be working there on work hours (your leisure time is your own!). So, it could be a solution that pleased everybody, if your reasons are just the circumstantial ones those stated above, and not a dislike with the program itself.

You would probably need to spend time refreshing things, and maybe even to rewrite many things from scratch. As long as the client (University) is ok with paying the needed hours at the wage agreed with your company, that's good for your company.

Note that while you seem to consider yourself unfit, you probably still are the most suited person to do it. Refreshing that prior knowledge is likely easier than learning and understanding everything for someone else.

There are many reasons it is unlikely that would actually work out (even if your company does services for other companies): the wages the University may be willing to pay are probably quite lower than the fees of your company, your supervisor may not have the needed funds for such a project, your managers may not with to enter into an unexplored business marked, your current projects may be much more profitable than anything the University could pay, etc.

However, if your supervisor can't reach an agreement with your company, it should no longer bother you, as you did present a solution but they didn't take it.

(maybe he would claim it wasn't affordable by them, but if someone wants a service that he cannot pay for, he is not entitled to have someone do it cheaper/for free, is he?).

Answer 9

Just say no. He can get omeone else to fix it or even rewrite it from scratch. Or even (if needed) to go over it line by line to understand it (e.g. if they need to keep doing followon comparisons). None of these is as convenient (meaning cheap) as you continuing on. But you're not being adequately compensated for the hassle factor.

Fact of the matter is academia, while it has its good points, also has well known inefficiencies. Non-production code. Students graduating and advisors who just put names on papers. Samples that get thrown out. Apparatus that morphs or dies. Work that never gets published. Etc. Etc. But it's not your job to fix that. You did your duty. Move on. Let the PI worry about it. It won't be the only hassle of this kind that he has.

Answer 10

Be honest and tell him you struggled to find a resolution that would satisfy everyone involved but finally realized it was beyond the limit of your abilities at which point you reached out for help and received much valuable feedback and that you would be grateful if it were to be improved on further by the inclusion of his own perspective and insight at Supervisor wants me to support a diploma-thesis software tool after I graduated

The fact of his seeing this helps ensure finding a course of action that results in the most good for the most number.

Also, better that you be the one to tell him now than he find this some other way.