Es zeugt leider von äußerst besch*** Fähigkeiten der Projektleitung die Entwickler durch Codereviews und penibles Branchingmodell seitens der Buildmanager von ihren “machen wa ma was” Ideen wegzubringen. Diese Magic wie sie einst John Carmack gebracht hat, geht heutzutage nicht mehr wenn der Dev dann selbst zu seinem eigenen Problem wird. Vielleicht hätte eine gewisse Gewinnbeteiligung am Produkt die Motivation gestärkt selbst dran zu bleiben.
Aber auch ein Entwickler kann nicht alles wissen. Vieles ist probieren, lernen, erneut probieren. Hast Du keinen 2. Entwickler der als sparring Partner dabei ist, verliert man schnell die Motivation und die Manieren ordentlichen Code zu entwickeln wenn es nicht das eigene Lebenswerk ist.
Mann kann mehrfach verschachteln um Stück für Stück an sein Ziel zu kommen. Man könnte natürlich auch mal komplexer denken und erstmal planen bevor man bastelt und iterativ vorgehen. Das aber ist auch in vielen Softwareprojekten nicht immer gegeben und wird dem Kunden als “komplett von Grund auf neu entwickelt” positiv verkauft. Dass da ein technischer Fail dahinter hängt, vermögen die wenigsten Nutzer dann zu schlussfolgern.
Insofern kann ich übgrigens den Aerosoft Bus als positives Beispiel nennen. Sie haben iterativ die Komplexität gesteigert und sich weiterentwickelt. Blöd nur dass bei gleichen Kosten ein besseres Produkt eines anderen Anbieters auf dem Markt existiert (wenn man alle Versionen gekauft hat).

Ich bezog mich auf die Entwicklungsweise bei Aerosoft. 😉
Was sind bei Dir alternative Fakten? Fakten können nur auf objektiven Tatsachen beruhen. Alternativ gibt es da nicht.
Ich bezog mich da eher auf meine eigene Entwicklungserfahrung und dem Vorgehen auf dem Softwaremarkt allgemeinhin. 😀

@Andy: Der Leser kann es so verstehen, als ob Du die Entwicklung des CRJs beschreibst – und da habe ich ganz andere Informationen. Selbst auf Aerosoft im Allgemeinen treffen Aussagen von Dir nicht zu. Man kann also nicht behaupten, dass Deine Aussagen auf objektiven Tatsachen beruhen. 😉