Thoughts on agile software development
“Ein entschlossener Mensch wird mit einem Schraubenschlüssel mehr anzufangen wissen als ein unentschlossener mit einem Werkzeugladen.“ Emil Oesch Mit JUnit 4.4 wurde die Hamcrest Bibliothek über die unscheinbare Methode assertThat Bestandteil des Test Frameworks. Obwohl schon einige Zeit vergangen ist, haben viele Entwickler das Potential dieser Ergänzung noch nicht entdeckt. Bislang werden in den Unit … Read more
Manche Entwickler halten Copy&Paste für das schlimmste Anti-Pattern in der Software Entwicklung. Leider muss man ihnen sagen, dass es noch schlimmer geht. Cargo Cult Programming ist die Verwendung von Pattern ohne sie zu verstehen. Dabei kopieren die Entwickler bestehenden Programmcode in der oft irrigen Annahme, dieser Programmcode wäre notwendig. Der folgende Programmcode entstammt einer tatsächlichen existierenden … Read more
“Never assume software developer skills when stupidity will suffice“
Jens Kaiser
Basierend auf Hanlon’s Razor und dem Paretoprinzip, besagt diese Regel, dass man grundsätzlich von fehlerhaften Sourcecode ausgehen sollte. Man investiert ansonsten zu viel Zeit, um nicht vorhandene Design-Pattern oder absichtsvolle Algorithmen zu entdecken.
Any software that can be written in JavaScript will eventually be written in JavaScript.
Wie verwandelt man eine Firma in eine agile Firma? Wenn man es schnell und billig haben will, dann kann man einen alten Kläpper mit schwarzer Schuhcreme in einen stolzen Rappen verwandeln. Der Traum endet jedoch beim ersten Regenguss und so ergeht es auch dem schnellen Start in die Agilität. Der frühere Projektleiter wird zum Product … Read more
Hin und wieder fragt ein Kollege, warum er seinen Code umstellen soll. Er würde ihn gut verstehen und andere könnten sich doch auch reinfuchsen. Das Einarbeiten in fremden Code ist aber immer wieder anstrengend und jede sinnlos vergeudete Minute summiert sich am Ende des Jahres in Tage oder gar Wochen. Ein recht triviale Regel lautet … Read more
YAGNI ist wohl eines der Prinzipien, die am schwierigsten einzuhalten sind in einem Entwickler-Team. Insbesondere wenn die Kollegen sich weiterhin daran klammern, dass Änderungen immer aufwendig und zeitraubend sind.