Er hat es wohl richtig gemacht. Ich war auch mal in einem "desorganisiertem" Unternehmen und dort war featuritis auch viel lieber gesehen, als Stabilität und gute Weiterentwicklung. Es ging sogar so weit, das Expertenmeinung einfach ignoriert wurde und das hatte auch Konsequenzen die fast in den Ruin des Unternehmens mündete. In solchen Fällen, nimm die Beine in die Hand und renn
Wenn es im Rahmen ist, ist das okay. Wenn aber Features um jeden Preis rein gepresst sein müssen, ist das schlecht. Ich denke das Problem von Martin war nicht, das er keine neuen Features wollte. Sondern es sollten zuerst die Rahmenbedingungen für die Features stimmen, und dann kann die implementierung stattfinden. Zumindest verstehe ich es so.
Bei meiner Software mache ich das genauso. Neue Features, ja. Aber erst wenn ich mir sicher bin, das der Unterbau stimmt. Wenn er nicht stimmt, mache ich den Unterbau passend (zb. durch Refactoring) und implementiere die dann neuen Features. Das erscheint zuerst langsam und mühselig zu sein, weil "nichts vorwärts geht". Richtig Speed bekommt man aber zur Zeit der Implementierung und letztendlich eine sauberere Software, die man auch besser pflegen kann.
Diese Zeit sollte man den Entwicklern lassen. Ansonsten bekommen die die ganze Kritik ab, wofür sie nichts können. Und die eigentlich Verantwortlichen dürfen sich im Ruhm "sonnen".
Er hat es wohl richtig gemacht. Ich war auch mal in einem "desorganisiertem" Unternehmen und dort war featuritis auch viel lieber gesehen, als Stabilität und gute Weiterentwicklung. Es ging sogar so weit, das Expertenmeinung einfach ignoriert wurde und das hatte auch Konsequenzen die fast in den Ruin des Unternehmens mündete. In solchen Fällen, nimm die Beine in die Hand und renn
Gerade hier wird doch sonst die KDE-"Featuritis" ggüber. z.B. GNOME sonst so gerne gelobt.
Wenn es im Rahmen ist, ist das okay. Wenn aber Features um jeden Preis rein gepresst sein müssen, ist das schlecht. Ich denke das Problem von Martin war nicht, das er keine neuen Features wollte. Sondern es sollten zuerst die Rahmenbedingungen für die Features stimmen, und dann kann die implementierung stattfinden. Zumindest verstehe ich es so.
Bei meiner Software mache ich das genauso. Neue Features, ja. Aber erst wenn ich mir sicher bin, das der Unterbau stimmt. Wenn er nicht stimmt, mache ich den Unterbau passend (zb. durch Refactoring) und implementiere die dann neuen Features. Das erscheint zuerst langsam und mühselig zu sein, weil "nichts vorwärts geht". Richtig Speed bekommt man aber zur Zeit der Implementierung und letztendlich eine sauberere Software, die man auch besser pflegen kann.
Diese Zeit sollte man den Entwicklern lassen. Ansonsten bekommen die die ganze Kritik ab, wofür sie nichts können. Und die eigentlich Verantwortlichen dürfen sich im Ruhm "sonnen".