Creo que con frecuencia, la tendencia a sentir que has caído en una madriguera de conejo con análisis exploratorios se debe a perder de vista la (s) pregunta (s) sustantiva (s) que estás haciendo. Lo hago yo mismo, de vez en cuando, y luego tengo que recordarme cuáles son mis objetivos. Por ejemplo, ¿estoy tratando de construir un modelo específico o evaluar la idoneidad de uno existente? ¿Estoy buscando evidencia de problemas con los datos (es decir, análisis forense de datos)? O, ¿está esto en las primeras etapas del análisis, donde estoy investigando preguntas específicas de manera informal (por ejemplo, ¿hay una relación entre dos variables?) Antes de pasar a desarrollar un modelo formal? En resumen, si se da cuenta de que está trazando parcelas y tablas pero no puede establecer claramente cuál es su objetivo inmediato o por qué esa trama / tabla es relevante, entonces sabe que '
Intento abordar el análisis exploratorio de datos como lo hago escribiendo, ya sea escribiendo un programa o escribiendo un artículo. En cualquier caso, no comenzaría sin hacer un bosquejo primero. Ese esquema puede cambiar (y con frecuencia lo hace), por supuesto, pero comenzar a escribir sin uno es ineficiente y, a menudo, produce un producto final deficiente.
En la organización WRT, cada analista debe encontrar un flujo de trabajo que funcione para él o ella; hacerlo es IMO más importante que tratar de seguir rígidamente el flujo de trabajo de otra persona (aunque siempre es útil obtener ideas de lo que otros están haciendo). Si está trabajando mediante programación (es decir, escribiendo código que se puede ejecutar para generar / regenerar un conjunto de resultados) y verificando su trabajo en git, entonces ya está muy por delante de muchos en este sentido. Sospecho que es posible que solo necesite dedicar un tiempo a organizar su código, y para eso, sugeriría seguir su esquema. Por ejemplo, mantenga sus archivos de análisis relativamente cortos y específicos, de modo que cada uno responda una pregunta específica (por ejemplo, diagramas de diagnóstico para un modelo de regresión específico). Organícelos en subdirectorios en uno o dos niveles, según el tamaño y la complejidad del proyecto. De esta manera, el proyecto se vuelve autodocumentado; una vista de lista de los directorios, subdirectorios y archivos (junto con el comentario en la parte superior de cada archivo) debería, en teoría, reproducir su esquema.
Por supuesto, en un proyecto grande, es posible que también tenga un código que limpie y administre los datos, el código que ha escrito para estimar un cierto tipo de modelo u otras utilidades que ha escrito, y estos no encajarán en el sustantivo resumen para su análisis de datos, por lo que deben organizarse en una parte diferente de la carpeta de su proyecto.
Actualización: Después de publicar esto, me di cuenta de que no había abordado directamente su pregunta sobre "callejones sin salida". Si realmente decide que un conjunto completo de análisis no tiene valor, entonces si está trabajando en git, siempre puede eliminar los archivos correspondientes con un mensaje de confirmación como "Abandonó esta línea de análisis porque no era productivo." A diferencia de arrugar lo que ha escrito y tirarlo a la basura, siempre puede volver a lo que hizo más adelante, si lo desea.
Sin embargo, creo que encontrará que si procede de un esquema en el que ha pensado un poco, tendrá menos llamados callejones sin salida. En cambio, si pasa tiempo investigando una pregunta que vale la pena y relevante, incluso si esto lleva a un resultado nulo o no resulta como esperaba, probablemente todavía quiera mantener un registro de lo que ha hecho y el resultado (en como mínimo, para que no cometas el error de repetir esto más adelante). Simplemente muévalos al final de su esquema, en una especie de "Apéndice".