Ein Modul einer Software sollte nur Verantwortung gegenüber genau einem Akteur haben, weil jede Verantwortlichkeit eine potentielle Quelle für Veränderungen ist. Die richtige Auftrennung dieser Verantwortlichkeiten ist ein zentraler Aspekt jeglicher Software- und Systemarchitektur. Sie entscheidet maßgeblich über Flexibilität, Modularität, Wiederverwendbarkeit und Wartbarkeit, kurz über die Qualität des Gesamtsystems. So einfach das Prinzip intellektuell zu verstehen ist, so schwer ist es in der Praxis umzusetzen. Zwei Symptome sind klare Hinweise auf eine Verletzung des Single‐Responsibility‐Prinzips: Starrheit und Zerbrechlichkeit. Im ersten Fall zieht jede Änderung an einer Stelle viele Änderungen an anderen Stellen nach sich, während im zweiten Fall Änderungen zu Fehlern in konzeptionell getrennten Bereichen des Systems führen. Nichts zu ändern ist aber keine Option, weil die Daseinsberechtigung von Software gerade ihre (einfache) Veränderbarkeit ist – abgesehen davon, dass der (persönliche) Erkenntnisfortschritt im wissenschaftlichen Kontext eine weitere Quelle ständiger Veränderungen ist.