ch weiß das hier zwei User sind, @rkdk und @Nachtschicht die nie Probleme mit Steinberg Produkte haben.
Kommt auch immer darauf an, wer welche Funktionen nutzt. Das kenne ich von allen Softwarepaketen, auch im Industrieumfeld. Wenn du das nutzt, was alle nutzen, ist schon einer drübergestolpert und der Hersteller hat viele bugs rausgeworfen. Wehe du nutzt ein tool exzessiv und beschreitest Wege, die etwas seltener genutzt werden - oder du hast was anderes als einen Standard-PC, dann wirst du zum Tester.
Ja, ich stimme zu: Vielen Herstellern stünde es gut zu Gesicht, mehr auf Stabilität und Test zu setzen, als einfach features rauszuhauen - aber systematisches Entwickeln nach Standards, methodisches Testen oder gar Regressionstests sind in der Consumer-Software-Landschaft kaum etabliert. Ich hatte schon mit verschiedenen Herstellern zu tun und auch mit dem output von Entwicklern, die aus der Audio-Brache kamen und kommen, z.T. auch von "namhaften Herstellern". Dort gibt es immer mehr Druck vom Markt und es werden oft Anfänger eingesetzt und es herrscht viel Fluktuation. Viele verlassen die Szene, um was anderes zu machen, weil sie sich mehr Bezahlung erhoffen. Mit Consumer-Audio ist eben nicht viel Geld zu machen. Die meisten dieser Bastelwurschtler kannst du aber nirgends gebrauchen, weil sie sich einen Hoppla-Hopp-Programmierstil angewöhnt haben. Also basteln sie weiter indem sie woanders als Audio-SW-Experte anheuern oder eine eigene Bude aufmachen und ihr Zeug verticken, bzw es als Modul einem Hersteller antragen. Dann braucht es dort nur einen findigen Projektleiter, der auf die grandiose Idee kommt, SW zuzukaufen, statt sie von der eigenen Chaostruppe basteln zu lassen und flux besteht ein Programm aus hunderten Brocken:
- Zukauf-Code, der angepasst werden muss
- Einschlepp-Code, den der neu eingestellte Entwickler mitgebracht hat
- Alt-Code, der aus vorheriger-Software-Versionen kommt und mit möglichst wenig Aufwand angepasst werden soll
- Dino-Code, den der Teamleiter mal programmiert hat und der nicht ersetzt werden darf, so beschissen er auch ist
- Tot-Code, der immer wieder mit eincompiliert wird, weil es ohne ihn nicht geht, aber keiner mehr weiß, was er tut
- DoNotTouchMe-Code, der keinesfalls geändert werden darf, weil niemand mehr von denen da ist, die den gemacht haben
Das alles muss zusammengebrutzelt werden. Hinzu kommen:
- die Versuche, sich an neue Technologien anzupassen, die im Team noch keiner je gemacht hat
- Treiber fürs WinDoof, deren API von MS schlecht dokumentiert ist
- Treiber erstellen, um Windoof zu umgehen, weil der MS-Mist nicht geht
Um all das sauber und sicher zu machen, bräuchte es die doppelte Zeit, die zur Verfügung steht, was aber auch daran liegt, dass Programmierer sich gerne selbstverwirklichen und das programmieren, was sie möchten und können und nicht das, was gebraucht wird oder der Kunde nutzen will. Das gilt besonders für die kläglichen Versuche, in Sachen Grafik kreativ zu sein