If you went into research you did so because you want to solve new problems. With no disrespect to software engineering, most (production) software engineering

If you went into research you did so because you want to solve new problems. With no disrespect to software engineering, most (production) software engineering involves solving old problems over and over again on a daily basis, with genuinely new problems tossed in only from time to time. This is even more the case when you’re maintaining a codebase that’s widely used. There is nothing wrong with solving old problems: that describes most useful human work. It’s just that finding and solving new problems is a very specialized kind of work, and it’s very hard to do that specialist work if you aren’t spending most of your time on it. You need to keep up with the literature and fight to stay at the forefront of your field and you can’t do that as a 20% time position. A good analogy here is like the interplay between a general contractor and a licensed electrician. The contractor could do their own wiring in between framing and drywall (and take the necessary tests and certifications to learn the code), but it usually makes more sense to have specialized contractors come in for that work. Unfortunately the problem described by this article is that the software developers (contractors) aren’t using the output of the researchers. Insofar as this is true it should be addressed. However the answer probably is not to have the specialized researchers do more general software development, which will just make everyone less efficient.