Intuition & Debugging

Bei der Zusammenarbeit mit einem Kollegen hat sich in diesem konkreten Fall gezeigt, dass ein nüchternes nur auf Rationalität und Logik basierendes Debugging sehr effizient sein kann. Allerdings dürfte es einem einzelnen Entwickler sehr schwer fallen, jeden Aspekt einer selbst geschriebenen Software ausschliesslich rational zu betrachten und gemäss den Grundsätzen der Logik zu analysieren.

Ich kenne das aus der eigenen Erfahrung. Vor allem, wenn man an sein Ziel kommen will, der Bug eigentlich nur nervt, dann ist man sehr oft dabei “intuitive Abkürzungen” zu nehmen. Das das sehr gefährlich ist und nur teilweise zum Erfolg führt, hat mich die eigene Coding-Praxis gelehrt. Denn so gut wie meine Fehleranalyse, war dann auch mein Code. Sprich, wenn die Probleme nur intuitiv bekannt sind, dann kann der erarbeitete Bugfix ebenfalls nur intuitiv richtig sein. Dass damit bereits die Grundlage für den nächsten Bug/-fix gelegt ist, erschliesst sich sicherlich jeden.

Bei der Arbeit als Projektmanager habe ich dabei zwei Szenarien erlebt: a) den Entwickler, der mit einer Software arbeitet (Open Source, Closed Source) welche Ihm nur zu einem bestimmten Prozentsatz bekannt ist. Zusätzlich erschwert wird das Thema, wenn die Sprache/Entwicklungsumgebung nicht 100%ige Nachvollziehbarkeit aller vom Code ausgeführten Aktionen sicherstellt. Hier habe ich Intuition von Entwicklern sehr zu schätzen gelernt. Wo bei es hier gigantische Unterschiede gibt, grundsätzlich gilt, wie im Wikipedia-Artikel nachlesbar: je mehr Arbeitserfahrung , desto besser die auf Intuition basierenden Ergebnisse.

b) Das zweite Szenario, ist z.B. die Arbeit mit Werkzeugen wie Python o.ä. Hier ist gewährleistet, dass jeder einzelne Schritt des Codes nachvollzogen und geprüft werden kann. Hier ist es immer besser, sich ausschliesslich rational dem Problem zu nähern und dieses Schritt für Schritt einzugrenzen. In der Regel ist man schneller, als mit Anzahl x intuitiven Versuchen den Fehler zu identifizieren.

Ein weiteres Problem ist mir vor allem bei der Arbeit mit Scriptsprachen aufgefallen. Die vermeintliche unmittelbare Überprüfbarkeit des Ergebnisses verleitet (bin of genug selbst Opfer gewurden) sich auf ein Try-and-Error-Coding zu verlassen. Wenn diese zusätzlich auf durch Intuition basierden Bugfixes verlässt, ist die Gefahr gross, das der Fehler nur oberflächlich behoben, aber nicht entgültig entfernt wird.

Grundsätzlich bin ich daher ein grosser Freund von Entwicklungssystemen (Sprache, IDE, Tools) welche grosse Transparenz bei der Softwareentwicklung sicherstellen. PHP (hier vor allem das Zend Studio) liefert hier eine recht gute Grundlage. Python ist allerdings hier deutlich besser, da die Sprache an sich besser lesbar und inhaltlich stringenter aufgebaut ist.

Python bietet darüber hinaus deutlich mehr Tools zur Nachvollziehbarkeit des Codes, als PHP. Das kann aber aus meiner Sicht auch ein Nachteil sein. Denn die Arbeitsweise des Softwareentwicklers (v.a. das rationale Analysieren vs. der bewusste Einsatz intuitiver Fähigkeiten) sind sicherlich deutlich entscheidender für das schnelle Finden der korrekten Fehlerursache. Die Tools können das nur unterstützen.

Tags: Agiles Projektmanagement, Coding, Intuition, Project Management, Rapid Development Frameworks, Rationalität, Software Development

This entry was posted on Monday, November 16th, 2009 at 9:10 pm and is filed under Agile Software Development, Coders best practice, PHP, Python, Rapid Development Frameworks. 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.