Ganz anders hingegen in der ENTSTÖRUNG! - Die alltägliche Entstörung schafft ja in der Regel nichts NEUES, sie entstört vielmehr etwas, das ja schon DA ist. - Und sie entstört es ja auch nur DANN, WENN es gestört ist; und das bedeutet:
Jeder 'burnt Track' in der Entstörung VERSTETIGT den Fehler. - Und wenn dann die 'burnt Tracks' gar nicht WAHR-genommen würden? - Dann passiert in der Entstörung etwas, was in der Entwicklung so NICHT passiert: Die Entstörung entgleitet als Ganzes.
Das wissen natürlich jene Entwickler, die auch zum ENTSTÖRER taugen. - Und noch etwas wissen sie: In der Entstörung muss man die 'burnt Tracks' nicht nur WAHR-nehmen, man muss sie Vorsichts-halber ALLE als einen ZUSÄTZLICHEN Fehler begreifen, der gegebenen Falles der SEPARATEN Entstörung bedarf. - Tut man das NICHT, dann ist die Gefahr viel zu groß, dass sich der ursprüngliche Fehler nicht nur VERSTETIGT, sondern obendrein noch VERBREITERT.
Hieraus ergibt sich, dass ein in die ENTSTÖRUNG geschickter Entwickler jeweils UMDENKEN muss. - Und geht es wieder zurück in die ENTWICKLUNG, dann muss er wiederum UMDENKEN; täte er das NICHT, dann wäre er als ENTWICKLER in seiner dortigen Productivität sehr schnell gemindert.
Und dieses jeweilige Umdenken bezüglich derer 'burnt Tracks' ist mit einer gewissen ANSTRENGUNG verbunden, und es kostet natürlich auch seine jeweilige ZEIT.
Und obwohl das eigentlich vollkommen KLAR ist, habe ich dennoch den Eindruck, dass unsere von der ENTWICKLUNG (tic) in die ENTSTÖRUNG (toc) geschickten Entwickler ohne Pause tic-toc-tic-toc, tic-toc-tic-toc hin und her springen müssen, an Statt ihnen einen viel gesünderen Rhythmus wie zum Beispiel tic-tic-tic-tic, toc-toc-toc-toc zu gestatten...
Wir werden das in RUHE besprechen. |
Thread abonnieren
