Vergangenen Freitag nachmittag sass ich mit einem Mitarbeiter zusammen vor seiner Arbeitsmaschine und gemeinsam waren wir auf der Suche nach einem Bug in seiner Software. Gemeinsam schauten wir durch seinen Code und ich liess mir Stück für Stück erklären, was nicht funktioniert, welche Codebestandteile beteiligt sind und welche möglichen Ursachen es geben könnte.
Unsere Zusammenarbeit sah in etwa so aus: er zeigte mir ein Stück Code und erklärte mir was es tat. Dann stellte ich Fragen zum Verständnis und liess mir die erwartete Funktionsweise erklären. Anschliessend prüften wir gemeinsam, ob der Code wirklich zu 100% ausführte, was wir erwarteten. Das ganze wiederholte sich 4-5 Mal, während sich folgendes abspielte.
Mein Mitarbeiter zeigte mir den Code, erklärte mir die Funktionsweise und hatte einen Aha-Effekt. Er brach mitten im Satz ab und Zitat: “Ich habs! Wart!” – woraufhin er sofort in eine andere Datei springen wollte… Ich stoppte Ihn lies mir seine Gedanken erklären. Hierbei äusserte er seine Vermutung (jedes mal eine andere), welche sich nach meiner Auffassung nicht direkt kausal aus dem eben betrachteten Code herleiten liess. Daher bestand ich darauf, dass wir erstmal die korrekte Funktionsweise von ebendiesen diskutieren. Dabei prüften wir eine Funktion, erhielten daraus logische Hinweise auf die Fehlerquelle in einer anderen Funktion. Prüften diese erneut und sprangen zur nächsten Funktion. Am Ende konnten wir damit den Fehler an einer anderen, ganz unerwarteten Stelle nachweisen.
Im Nachgang daran habe ich mir gestern und heute ziemlich viel den Kopf verzbrochen, was da eigentlich passiert ist und was wir daraus für die Zukunft lernen können. Folgende Fragen stellen sich mir dabei: was lernen wir daraus? Können wir das in unserem Entwicklungsbetrieb nutzen? Welche Vorteile lassen sich dadurch erzielen? Meine Gedanken hierzu werde ich in den nächsten Tagen hier niederschreiben.
Tags: Coder, Coding, Developer, Entwickler, Intuition, Optimierung IT Projekt, Rationalität, Software Development
This entry was posted on Sunday, November 15th, 2009 at 8:46 pm and is filed under Agile Software Development, Coders best practice. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.
[...] « Rationalität vs. Intuition [...]
Naja,
den Fehler hat dann aber doch der erklärende Mitarbeiter gefunden und nicht der Fragende 
Also lass dich mit dem Problem vollquatschen, bis es bei dem Programmierer “klick” macht und schon biste wieder raus der Sache. Sinnvolle Fragen sind selbstredend angebracht. Ich haben dazu eine Fr.. im Haus. Hat keine Ahnung aber eben eine andere Sichtweise. Und nur daruaf kommt es an.
Gruß Veliks
Hi, das Schema, dass einer fragt, der andere erklärt und der Erklärende dadurch die Lösung findet, kenne ich natürlich aus eigener Erfahrung.
Hier allerdings ging es mir eher darum, dass ich bei der Zusammenarbeit feststellte, dass viele Entwickler grundsätzlich beim Debugging zwischen “es könnte daran liegen” = Intuition und sauberem auf Logik basiertem Tracking und damit eindeutigen eingrenzen des Fehlers springen. Vor allem passiert das oft, wenn man ersten Versuchen nicht sehr weit kommt.
“Ich haben dazu eine Fr.. im Haus. Hat keine Ahnung aber eben eine andere Sichtweise.”
–> crasse Ausdrucksweise…
Ich hätte auch sagen können, ich frage jemanden auf der Strasse ob er Zeit hat und ich ihn vollquatschen könne, sorry, wenn sich jemand betroffen fühlt.
Habe jetzt verstanden: Nur was ist der Unterschied zwischen Logik und Intuition. Nach diesem Diskurs gibt es wohl nur einen klitzekleinen Unterschied. Kann ich es erklären ist es Logik, kann ich es nicht erklären ist es Intuition?
Wenn ich es erklären kann, kann ich es einer Software beibringen, kann ich es nicht erklären, dann funktioniert die Software nicht sehr lange. Spätestens beim nächstes co-Level wars das.
Also muss Software so geschrieben werden, dass die Software selbst den Fehler ermittelt und gleichzeitig am Computer des letzten Coders der Fehlerzeile eine “rote Lampe” angeht.
Schon mal daran gedacht die Software komplett datenbankgestützt zu programmieren? Das Pair Programming ist ja bereits Grundlage im Unternehmen.
Habe jetzt verstanden: Nur was ist der Unterschied zwischen Logik und Intuition. Nach diesem Diskurs gibt es wohl nur einen klitzekleinen Unterschied. Kann ich es erklären ist es Logik, kann ich es nicht erklären ist es Intuition?
so einfach ist das aus meiner sicht nicht. hier geht es nicht um: “was ist die ursache des fehlers?” sondern um “wie finde ich den fehler?”
d.h. finde ich den fehler indem ich mir innerhalb einer zu betrachtenden methode fehlerquellen ausschliesse. und die übrigbleibenden mir anschaue. in jeder dieser potentiellen fehlerquellen gehe ich identisch vor. damit kann ich mich von methode zu methode hangeln und komme unweigerlich direkt zum fehler. gern können wir das mal gemeinsam machen.
hintergrund ist der, dass wir hier immer von skriptsprachen reden. da diese sequenziell hintereinander ablaufen, kann ich immer vom ende (sprich output) aus mich rückwärtsbewegen und die ursache logisch stringent ermitteln.
ist das jetzt verständlicher?
Dieser Weg führt mit Sicherheit zum Erfolg. Aber ist er effizient? Manchmal findet man ja im Wirrwar gar keinen Anfangspunkt, dann ist das die einzige Variante, “Back to the roots”
Dieses Zahlenspiel: Rate eine Zahl zwischen eins und 127 mit maximal sieben Frage, kennt jeder. Stückchenweise eingrenzen, …
Insofern ist wohl verständlich, warum Programmierer in manchen Fällen total “chaotisch” (Intuitiv oder auch nicht) vorgehen. Und natürlich laufen Skriptsprachen sequentiell ab, nur ist das OO Programmiermodell dafür eigentlich nicht gemacht. Eher doch für die konkrete Aufgabenverteilung im Code in immer kleinere Einheiten (Vereinfacht wegen dem Disput um Daten- oder Funktionsortientierung).
Was ist ein Fehler? Diese fast philosophische Frage beschäftigt mich seit Beginn meiner Proggikarriere.
Ein erster provokativer Ansatz wäre: Ein Fehler ist ein nicht ausprogrammiertes Feature.
Andererseits gibt es Fehlerabfangmechanismen, die mich aber keinesfalls befriedigen, denn genau jeder abgefangene Fehler ist genau ein ausprogrammiertes Feature.
|so einfach ist das aus meiner sicht nicht. hier geht es
|nicht um: “was ist die ursache des fehlers?” sondern um
|“wie finde ich den fehler?”
Diesen Unterschied speichere ich mir in meine Sammlung “Was war zuerst da? Die Henne oder das Ei” Den Fehler finden ist recht einfach – die Ausgabe zeigt nicht das erwartete Ergebnis. Warum kommt es zu dieser und nicht der erwarteten Ausgabe? – Diese Frage scheint mir hier besser gestellt.
Dem Menschen passieren auch Fehler, viel wichtiger ist eben genau eine Kontrolleinheit, die dafür sorgt Fehler zu erkennen. Und wo die Kontrolleinheit bereits da ist, könnte sie ja auch bereits die Fehlerursache und den Fehlerort mitliefern.
Bei Gelegenheit nehme ich Ihr Angebot an. Mal sehen, wann es passt und ich in Dresden Zeit finde.