Many aspects to software may be invisible in a performance. Here are a few that came to mind:
– Lost history: Time spent can be rendered invisible (either to the audience, or for the artist themselves) in the process of maintaining a codebase on a project – versions offer unique and useful aspects to the work, but might be entirely absent for the audience. Because this history is hidden (whether that be meeting notes, themes in revisions, design challenges/failures, etc.), an opportunity could be lost for this discourse to engage with the art.
– Expectations: Initially assigned roles involving interdisciplinary collaborations can limit participants’ ability to increase quality in art or technology. For example, the way programmers solve problems may be invisible in an artistic “deliverable”. Similarly, the way performers move or process ideas might not affect the design choices of a programmer as a piece develops. If it were more commonplace for participants with diverse backgrounds to collaborate on unified aspects of art practice, I think technology could evolve with the pieces it serves.
– Software usability: When general purpose software (operating systems, device drivers, etc.) works well to a point of usability standards, users might not notice an elegance in the code. On the other hand, programs written for a particular creative work can get a team through a premiere and remain unusable outside of the situation of that art practice.