Ohne Fleiß kein Preis
Die derzeit langen Arbeitszeiten fordern wohl allmählich ihren Tribut.
Um einem Fehler auf die Schliche zu kommen, führten mein Kolege und ich den Programm-Code Schritt-für-Schritt aus. An einer Stelle, die uns wichtig erschien, starteten wir zusätzlich die Suchfunktion des Editors und suchten nach allen Vorkommen einer bestimmten Variable.
Die Variable wurde häufig benutzt und so suchten wir im Code fleißig weiter nach dem Fehler, und zwar nach wie vor Zeile für Zeile.
Der große Schreck!
Wieso sprang die Textmarkierung plötzlich mehrere Zeilen weiter als erwartet? Das dürfte nach der Programmlogik überhaupt nicht passieren!
Des Rätsels Lösung
Wir hatten ediglich die Textmarkierung der Suchfunktion weitergeklickt, nicht aber die Code-Ausführung. Wir hatten es nur nicht gemerkt, weil besagte Variable in fast jeder Zeile vorkam und die Suche nach ihr dewegen fast wie die schrittweise Ausführung des Programms aussah.
Dass so etwas zwei Leuten, die zusammen auf den Code sehen passiert, spricht vor allem dafür, dass die Uhrzeit zu spät und die Erhohlungszeit zu kurz war.
Ich brauche mal Urlaub.
Donnerstag, November 23, 2006
Die 100-Stunden -Woche
Manche Tage sind Mist.
Letzter Dienstag war so einer.
Da hätte die Abnahme der Software sein sollen, die ich mit einem Kollegen zusammen entwickelt habe und inzwischen weitgehend alleine betreue.
Das Plus 1 Phänomen
Wie das mit Abgabeterminen jeder Art so üblich ist, so fehlt am Ende immer das letzte Quäntchen Zeit, um das Programm "wasserdicht" zu bekommen. Ich habe mal gelesen, das so etwas als das "Plus 1 Phänomen" bezeichnet wird. Es fehlt immer genau eine Zeiteinheit mehr als man zur Verfügung hat. Sprich: Es man bräuchte nur eine Stunde mehr, um das Referat fertig zu stellen, oder eine Woche mehr für die Diplomarbeit oder - in meinem Fall - einen Tag mehr für ein stabiles Setup.
Zeit und andere knappe Ressourcen
Derzeit äußert sich das so, dass wir am Montag von 9:00 Uhr (morgens) bis um 2:00 Uhr (leider auch morgens) dafür schuften mussten. Zusammen mit besagtem Kollegen bereiteten wir nach bestem Wissen und Gewissen alles vor und, soweit es eben unter den gegebenen zeitlichen Umständen verträglich war, testeten so gut es ging.
Als ich tatsächlich im Bett lag, war es immerhin schon 3:20 Uhr, wirklich schlafen konnte ich zu allem Überfluss aber nicht. Am Ende bekam ich gerade einmal 2,5 Stunden Schlaf, denn ich musste schon um 7:30 Uhr beim Kunden sein, um die DVDs abzuliefern.
Geiselhaft
Mein Plan war einfach:
Kaum, dass ich die DVDs abgegeben hatte, beschloss die Projektleiterin dort, erst einmal die DVDs auf Lesbarkeit in den Laufwerken zu prüfen. Damit hatten wir in der Vergangenheit leider schlechte Erfahrungen gemacht, insofern war diese Sorge nachvollziehbar.
Anstatt aber die Scheiben eine nach der anderen in das Laufwerk zu schieben und so zu sehen, ob es mit den gebrannten DVDs zurecht kommt, wurde gleich das Setup gestartet. An dieser Stelle wurde mir klar, dass ich nicht mehr weg gelassen würde, bis die Installation mit allen DVDs fertig war.
So wurde ich zur Dienstleistungs-Geisel.
Und siehe da, nachdem mein Kollege und ich uns die Nacht um die Ohren geschlagen hatten, gingen trotzdem noch Dinge schief. :-(
Das war wohl nix mit dem frühen Feierabend!
Im Gegenteil, der Arbeitstag war wieder überdurchschnittlich lang. Immerhin nicht ganz so extrem wie der Vortag, aber Montag und Dienstag zusammen erreichte ich dennoch eine gesamte Arbeitszeit von 32 Stunden!
Durchhalten, bald ist es vorbei!
Letzter Dienstag war so einer.
Da hätte die Abnahme der Software sein sollen, die ich mit einem Kollegen zusammen entwickelt habe und inzwischen weitgehend alleine betreue.
Das Plus 1 Phänomen
Wie das mit Abgabeterminen jeder Art so üblich ist, so fehlt am Ende immer das letzte Quäntchen Zeit, um das Programm "wasserdicht" zu bekommen. Ich habe mal gelesen, das so etwas als das "Plus 1 Phänomen" bezeichnet wird. Es fehlt immer genau eine Zeiteinheit mehr als man zur Verfügung hat. Sprich: Es man bräuchte nur eine Stunde mehr, um das Referat fertig zu stellen, oder eine Woche mehr für die Diplomarbeit oder - in meinem Fall - einen Tag mehr für ein stabiles Setup.
Zeit und andere knappe Ressourcen
Derzeit äußert sich das so, dass wir am Montag von 9:00 Uhr (morgens) bis um 2:00 Uhr (leider auch morgens) dafür schuften mussten. Zusammen mit besagtem Kollegen bereiteten wir nach bestem Wissen und Gewissen alles vor und, soweit es eben unter den gegebenen zeitlichen Umständen verträglich war, testeten so gut es ging.
Als ich tatsächlich im Bett lag, war es immerhin schon 3:20 Uhr, wirklich schlafen konnte ich zu allem Überfluss aber nicht. Am Ende bekam ich gerade einmal 2,5 Stunden Schlaf, denn ich musste schon um 7:30 Uhr beim Kunden sein, um die DVDs abzuliefern.
Geiselhaft
Mein Plan war einfach:
- die DVDs abliefern
- zurück nach Hause
- ein Stündchen Schlaf nachholen
- und dann zur Arbeit fahren.
Kaum, dass ich die DVDs abgegeben hatte, beschloss die Projektleiterin dort, erst einmal die DVDs auf Lesbarkeit in den Laufwerken zu prüfen. Damit hatten wir in der Vergangenheit leider schlechte Erfahrungen gemacht, insofern war diese Sorge nachvollziehbar.
Anstatt aber die Scheiben eine nach der anderen in das Laufwerk zu schieben und so zu sehen, ob es mit den gebrannten DVDs zurecht kommt, wurde gleich das Setup gestartet. An dieser Stelle wurde mir klar, dass ich nicht mehr weg gelassen würde, bis die Installation mit allen DVDs fertig war.
So wurde ich zur Dienstleistungs-Geisel.
Und siehe da, nachdem mein Kollege und ich uns die Nacht um die Ohren geschlagen hatten, gingen trotzdem noch Dinge schief. :-(
Das war wohl nix mit dem frühen Feierabend!
Im Gegenteil, der Arbeitstag war wieder überdurchschnittlich lang. Immerhin nicht ganz so extrem wie der Vortag, aber Montag und Dienstag zusammen erreichte ich dennoch eine gesamte Arbeitszeit von 32 Stunden!
Durchhalten, bald ist es vorbei!
Dienstag, November 21, 2006
Was ist Refactoring?
Kurz und knapp gesagt, ist Refactoring das Umbauen von Programm-Code, um dessen Effektivität zu erhöhen, ohne dass sich nach außen hin dessen Funktion ändert. Typischerweise wird refaktoriert, um Code lesbarer, kürzer oder schneller zu machen.
Aus dem Leben eines Programmierers:
Nun habe ich eine Code-Stelle mit 7 Zeilen, deren Funktionsweise erweitert werden soll. Daraus wurden dann ca. 50 Zeilen.
(Das ist noch kein Refactoring.)
Diese wurden zur besseren Lesbarkeit umgebaut, und siehe da, da waren es nur noch 17.
(Jetzt ist es Refactoring.)
Da sich diese 17 Zeilen aber anscheinend Außenstehenden, die sich nicht schon in das Problem eingelesen haben, nicht so offensichtlich erschlossen wir mir (was ja kein Wunder ist, nachdem ich stundenlang darüber brütete...), wurde der Wartbarkeit wegen alles NOCH EINMAL umgebaut. Ich bin wieder bei 50 Zeilen, dafür über 3 Funktionen verteilt.
(Trotz der neuen Funktionen ist es Refactoring, da die öffentliche Sichtbarkeit noch die selbe ist.)
Das Ergebnis des Refaktoring:
Nach stundenlangem Grübeln, Umbauen und Testen passiert am Ende immer noch exakt das Selbe wie vorher...!
Das ist das Programmiererleben. :-)
Aus dem Leben eines Programmierers:
Nun habe ich eine Code-Stelle mit 7 Zeilen, deren Funktionsweise erweitert werden soll. Daraus wurden dann ca. 50 Zeilen.
(Das ist noch kein Refactoring.)
Diese wurden zur besseren Lesbarkeit umgebaut, und siehe da, da waren es nur noch 17.
(Jetzt ist es Refactoring.)
Da sich diese 17 Zeilen aber anscheinend Außenstehenden, die sich nicht schon in das Problem eingelesen haben, nicht so offensichtlich erschlossen wir mir (was ja kein Wunder ist, nachdem ich stundenlang darüber brütete...), wurde der Wartbarkeit wegen alles NOCH EINMAL umgebaut. Ich bin wieder bei 50 Zeilen, dafür über 3 Funktionen verteilt.
(Trotz der neuen Funktionen ist es Refactoring, da die öffentliche Sichtbarkeit noch die selbe ist.)
Das Ergebnis des Refaktoring:
Nach stundenlangem Grübeln, Umbauen und Testen passiert am Ende immer noch exakt das Selbe wie vorher...!
Das ist das Programmiererleben. :-)
Abonnieren
Posts (Atom)