[zem]

If you argue that supporting the GUI is an undue burden, you're merely shifting that burden onto everyone who has to perform the same steps manually every single time. Automating or away may be more up front work, but it only needs to be done once.

[ddingus]

Until it needs to be done again.

Things change. It's a balance between the pay off and the ongoing investment to maintain the automation.

[zem]

right, but it needs to be done again by the single person maintaining the automation tools, who presumably is more of the "programmer" than "user" inclination. everyone else in the lab benefits.

[ddingus]

And who is that exactly?

For long established, regularly used tools, there is a case for funding this activity somehow.

For the many specialized tools? I'm not sure how this would actually happen, unless the person who creates it decides to maintain it. When their career focus doesn't value that tool, we can't really expect anything.

Worse, let's say some established systems exist. They have a barrier to entry in that new software needs to be compliant and potentially integrated on some level. People already are focused away from this stuff. Raising that bar means fewer overall contributions.

Now, it's often: I wrote this. It's open. You can use it.

And they move on.

If, suddenly, I wrote this, and it's open gets followed up by, "you need to make sure this works with all this other stuff..." what happens?

[zem]

i meant, if there is an organisation (the OP's example involves a university department, but this holds for other places too) where the majority of people simply want to use computers to get their work done, it is well worth having one person (or a team, as things scale up) whose job is to automate all the incidental details of working with the operating system and environment, so that people don't have to context switch from a "user" to a "programmer" perspective all the time.

[ddingus]

Seems to me those people, or person would also have to be pretty great generalists.

A lot of research type tools get written and then left laying a out. Just testing and packaging, integrating, etc... would be a considerable project.

Could be the basis of some sort of course or career though. I'm thinking of the sysadmin types who manage software and research teams outside academia. The really good ones I know used to hold a position, or have some personal interest sufficient to make these sorts of activities make sense.

[zem]

check out this post about twitter's "engineering effectiveness" team: http://www.gigamonkeys.com/flowers/

in general, it's a great productivity booster across the board to have a team doing this; the main problem is getting buy-in from orgs, because the time and effort wasted when you don't have one are so pervasive as to be largely invisible.