R, D and in between

Having worked in a company that had such a split before, I&#x27;ll admit to having been a bit resentful of being on the &#x27;D&#x27; side.<p>In many cases someone would decide that a particular problem (not a bug, but maybe something like optimisation of threading strategy for scalability) needed the &#x27;R&#x27; folks to look into it. Invariably what came back weeks later was something that I could have come up with in an afternoon, but without a PhD I wasn&#x27;t considered clever enough to put forward such stuff.<p>Still, apparently when the money was tight the Rs were the first to get axed...

I feel silly for expecting this to be about the languages.

I agree that there is value in having a team handle both the research &amp; development phases. That said, you may not need the full team to handle research. Not all team members may be interested in research related tasks or have the discipline to execute effectively on them.<p>From a company standpoint the challenge is to make the research phase valuable, even when the results are not positive. With limited resources, it is tough to balance too much or too little research. As the phase is harder to plan for, you are usually stuck with some timeboxed effort. There is immense pressure for that timeboxed effort to provide some direction for moving forward.