I like my supervisor but not how he does things; What do I do? I've already got a little experience doing self-led research but not in doing setup for the domain in which I work. I really enjoy talking with my supervisor about actual research topics, but I don't enjoy the workflow he suggests.

For example, there is a particular software development toolkit I've been told&dagger; to use, but it's constructed in such an unorthodox way as to be unusable outside of a certain development environment in a very specific way (in Eclipse IDE) and isn't compatible with development conventions which are nearly ten years old (Maven). I only found this out when it was too late and have had to jury-rig everything as I go, and now, due to having thrown together a bunch of weird stuff together without testing it properly (having been given the green light by my supervisor, respecting his decision that it would work fine), I've spent six months collecting data which is messed up to the point of being unusable. My supervisor was also surprised, admitting that he didn't expect any sort of problem like that (which is why he recommended throwing the said things together).

I like and respect my supervisor but can't help but feel the whole project has gone sour thanks to "just doing it the simple way" which has turned out to be unbelievably complicated and now it's very likely I spent all that effort for nothing. What can I do when I respect my supervisor's research advice but don't like doing things the way he does? &mdash; What kind of "workflow" can I form where I take his research advice but still do things "my" way... or at least to know what implementation advice I should take with a grain of salt? Obviously it works well for him, so I feel even more disillusioned that I'm the one with all these problems. I feel that just saying "no, your software doesn't work" would not be constructive, because it does seem to work... for him.



&dagger; Being more sure of the nature of the working relationships at the department, I now feel that I could have politely declined at the time without offending said person as long as I was confident and produced results.
First, research doesn't come with a specification with all details ironed out.  In most cases, many things are undefined and unknown; hence, it is called research.  We could change direction at any time, especially when we realize there is a better problem or the problem at hand is rubbish.  Consequently, the code in academia is pretty bad, poorly designed, and ad-hoc as compared to what you find in the industry; although codes in the industry can be one bowl of spaghetti too.

On your question, think about the problems at hand.  Try to plan them out as best as you can.  Collect evidence to justify the strength and weakness of a given tool/solution.   Bring these pieces of evidence to your supervisor.  If he/she is rational, he/she will either side with you or give you better reasons to not go a certain way.