Die Software soll vor allem richtige Ergebnisse liefern.
Hierfür ist es vor allem wichtig, ständig zu testen. Jede Schleife und jede Bedingung eines Moduls muss getestet werden.
Nur wenn man alle möglichen Umstände eines Programmes im Blick hat, ist es auch möglich entsprechende Rückfragen an die Fachabteilung zu stellen, wie etwa "was soll passieren, wenn das oder das zutrifft" oder "könnt ihr ausschließen, dass..." oder "ist es wirklich das, was ihr euch vorstellt?"

Alle Programme und Module müssen so programmiert werden, dass sie nachvollziehbar sind. Sonderlocken und Einzelfälle der Verarbeitung müssen vermieden werden. Programme müssen übersichtlich gestaltet werden und dürfen nicht zu lang sein. Im Zweifel ist es besser zu viel, als zu wenig zu kommentieren.
Bei der Realisierung eines Projektes arbeiten wir immer als Team und müssen im Kopf haben, dass ein anderer an der gleichen Stelle weiterarbeiten wird. Gerade als Freiberufler ist es ein zentraler Teil des Jobs, fertige Software an die Linie zu übergeben, sich also selbst überflüssig zu machen. Das funktioniert nur dann, wenn die internen Mitarbeiter mit dem System umgehen können.

Systeme sollen unter allen zulässigen Bedingungen klaglos durchlaufen. Hierzu ist es wichtig Integrationstests zu machen und alle möglichen Umstände zu identifizieren, unter den die Programme laufen müssen, leere Tabellen, unvollständige Quelldaten oder so. Ein Programm darf nur dann abbrechen, wenn das so gewollt ist.

Unter Umständen ist es wichtig, dass ein Programm abbricht, bevor es absoluten Mist produziert. Das ist besonders dann wichtig, wenn man Ergebnisse nach außen liefert, an Auskunfteien, Kunden oder so. Vorgänge eben, die man nicht mehr rückgängig machen kann.
Somit ist es wichtig, sensible Stellen zu identifizieren, Plausibilitätstests und gewollte Programmstopps oder gewollte Programmabbrüche zu realisieren.

Funktionen, die in einem Projekt mehrfach vorkommen, müssen an einer Stelle zusammengefasst werden. Sie dürfen nicht mehrfach programmiert werden.

Dadurch gewährleistet man, dass Inkonsistenzen vermieden werden. Das Projekt wird übersichtlicher, weil man Zusammenhänge besser erkennt und das Ganze wird produktiver, weil es nur ein Mal umgesetzt und vor allem auch nur ein Mal getestet werden muss.

Ein guter Teil bei der ETL-Entwicklung besteht ja immer auch in der Datenreduktion. Es ist gut, Filter möglichst weit vorne zu setzen und Daten möglichst früh zu aggregieren.
Wenn man es schafft, übersichtlich zu programmieren, dann hat man auch eine höhere Chance, performantere Programme zu schreiben.

Es gibt Situationen, bei denen die Ergebnisse eines Programms zufällig sein können, z. B. bei der Sortierung. Diese Situationen sind zu vermeiden, weil das Ganze sonst nicht richtig testbar ist.

Ökonomen lieben ja magische Dreiecke, Vierecke und alle magischen Vielecke. Hier ist es genauso. Wir müssen immer abwägen, ob jetzt die Performance oder die Nachvollziehbarkeit wichtiger ist, ob man Funktionen zusammenfassen möchte, oder ob es doch zu viele Abweichungen bei der Verarbeitung gibt.
Hier wird es immer Entscheidungen im Einzelfall geben, ein Best Practice für das Projekt muss gefunden werden.