Produktivitätskiller für Programmierer: Fix it later mentality

0
Blog is deprecated - Neu blog.nevercodealone.de
Webdesign TYPO3 Duisburg Produktiv Killer Quelle Infoworld

Webdesign TYPO3 Duisburg Produktiv Killer Quelle Infoworld

Auf der einen Seite ist es sicherlich gut, wenn ein Programmierer selber Prioritäten setzen kann. Aber hierfür braucht man sehr viel Erfahrung und auch den berühmten Blick über den Tellerrand. Auch Primadonna Developer sind hier mit Vorsicht einzusetzen. Für diesen Fall gibt es natürlich auch Ansprechpartner in Entwicklerteams. Leaddeveloper und natürlich auch Projektmanager können hier gefragt werden. Dabei kommt aber auch gleich ein Problem auf. Wenn eine einfache Frage eine Gruppen E-Mail mit an 6 Leute + 4 CC inklusive Kunden auslöst oder man als Entwickler, der sich in dem Moment schon aus zeitlichen Gründen für eine Sache entscheiden muß noch in eine kurzfristige Meeting Runde berufen wird, ist das Horror. Und auch unangenehm. Schließlich ist man ja Auslöser dieser Unannehmlichkeit.

I fix it later und wie der Horror entsteht

Kosten Bugs in PHP Webdesign Projekten Quelle Judith Andresen

Kosten Bugs in PHP Webdesign Projekten Quelle Judith Andresen

Natürlich gibt es die Situationen, in denen man etwas auf die lange Bank schiebt, weil man es selber in dem Moment entsprechend runter priorisiert. Das können im Frontend Browserprobleme sein, und auch im Bereich der Applikation ein Logfile, das voll läuft oder auch falsch gesetzte Userrechte im System oder Datenbanken. Andere Beispiele wären auch eine fehlende Übersetzungsfunktion, wenn die Sprache eh erstmal in nur einer Sprache erscheinen soll.

Einen Bug, den man als Entwickler findet, sollte man direkt beheben oder in einem Ticketsystem festhalten. Das ist dann keine Schande. Man kann hier auch eintragen, ob es ein Schönheitsfehler oder eine Sicherheitslücke ist. Wichtig ist, daß es nicht vergessen wird. Wenn das nur als Todo im Quellcode vermerkt wird, dann kann man das auch fast mit der unsichtbaren Schreibmaschine von den Simpsons festhalten. Hier ist auch wieder Charakterstärke eines Entwicklers gefragt. Also man darf ja Bugs haben. Die zu fixen ist gut und wichtig. Betrachtet man die Kosten, die ein Bug in Webdevelopment Projekten zum Zeitpunkt seiner Entdeckung verursacht, ist das eine extrem stark ansteigende Kurve.

Wenn man dazu noch mal aufführt, daß sich ein Entwickler bei den eigenen Stunden verschätzt, wird es dann natürlich am Ende in der kritischen Phase eines Projekts extrem hinderlich. Ein Fehler ist ein Fehler und wird irgendwann dann auch „live“ seine Bühne finden. Das kann beim Errorlog Samstag Nacht oder am ersten Weihnachtstag passieren. Und das kann natürlich auch bei einer Präsentation beim Kunden, der den Internetexplorer in einer älteren Version nutzt auftreten. Prioritäten verschieben sich eben halt auch und ändern sich. Die kann man nicht einmal festlegen.

Beides ist dringend zu vermeiden. Auch ist es ja so, daß Arbeit Arbeit macht. Und die bekanntlich nicht weniger wird.

Fazit zu der „I fix it later“ Mentalität
Mit Bugs läuft die Webdesign Applikation nicht sauber. Es kann nicht der Anspruch eines professionellen Webdevelopers sein, einen Bug in seinem System zu haben. Ein Bug ist dabei auch vergleichbar mit einer Infektion in der Applikation. er kann wachsen und ausarten. Das schlimmste ist, wenn man ihn aus dem Development Stadium mit ins Live System nimmt. Spätestens hier ist er nicht mehr unter Kontrolle. Sicherheitsrelevante Bugs sind hier auch eine echte Gefahr. Die geht natürlich nicht von einer fehlenden Übersetzungsfunktion aus. Aber auch das kann natürlich auch ärger machen, wenn es einfach gerade im Moment nicht passt.

Leider kann man nicht jeden Bug vermeiden und auch nicht immer direkt fixen. Gerade in bestehenden Internet Applikationen kann es aus der Historie schon echte Bugnester geben. Die braucht keiner. Die müssen aktiv bekämpft werden. Je eher desto besser.

Weiterführende Links zum Thema Bugs in Internet Applikationen:
Beitrag bei der Hamburger PHP Usergroup von Projektcoach Judith Andresen zum Thema der Wirtschaftlichkeit von Tests während der Entwicklung
http://www.judithandresen.com/2013/04/10/phpughh-betriebswirtschaft-testgest%C3%BCtzte-php-entwicklung/

Betriebswirtschaft + testgestütztes Arbeiten in PHP-Projekten von Judith Andresen

About Author

PHP Kurs und Inhouse Schulungen für Webdevelopment mit Continuous Integration - Clean Coder, Blogger, Autor, Dozent und Senior Webdeveloper www.rolandgolla.de

Leave A Reply

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre mehr darüber, wie deine Kommentardaten verarbeitet werden.