Falsch. Die Reihenfolge ist: Make it work, make it right, make it fast.
Das ist eine Betrachtungsweise. Eine andere ist: Worauf kommt es bei der (Software)Entwicklung vorangig an?
Ich kann ein Problem übrigens grundsätzlich lösen, ohne Code produziert zu haben. Das ist eigentlich meistens so. Und das hat was mit Qualitätsbewusstsein zu tun.
Zitat:
Wenn es funktioniert, dann ist der Code in aller Regel auch ziemlich schnell aufgeräumt. Wenn er dann aufgeräumt ist kann man noch anfangen, ihn zu optimieren ohne ihn wieder kaputt zu machen.
Das geht nur, wenn man (halbwegs) guten Code geschrieben hat. Und das geht nur, wenn man wartbaren Code geschrieben hat. Und das geht nur, wenn man testbaren Code geschrieben hat. Und nur(!) wenn man testbaren Code geschrieben hat, kann man ihn in Ruhe optimieren und aufräumen. Wo fängt es also an? Bei gutem Code und Qualitätsbewustsein? Oder beim 'Hauptsache et läuft'. Schrottcode wird nie guter Code. Nie. Aber guter Code wird sehr schnell funktionieren.
Ich muss dir das alles nicht erklären und die agile Softwareproduktion will ja den Theorieschnulzen endlich das Handwerk legen und das ist auch gut so. Apropos Handwerk: Erst mit einem gewissen Maß an handwerklichem Können wird das 'Make it work, make it right, make it fast' überhaupt machbar. Ein Haus aus Pappkarton, das den ersten Regen abhält, wird niemals ein Haus aus Stein mit negativer Energiebilanz. Aber ein halbwegs gut gebautes Haus kann nachträglich problemlos optimiert werden. Allerdings muss das Fundament und die Mauern stimmen.
Du gehst davon aus, das man automatisch halbwegs knetbaren (=optimierbaren) Code schreibt. Davon kannst Du aber nicht ausgehen, weil das Quatsch ist. Leider. Code ist -ohne das man mit der Peitsche hinter den Programmierern steht- fast immer Müll. Leider meine Erfahrung. Natürlich, wenn man handverlesene Spezialisten hat, die gut geschult sind und sich weiterbilden, dann... klar. Aber nicht bei einem durschnittlichen Frickelverein oder gar einer IT-Abteilung eines Piepenbrinkbetriebes.