¿Cuándo deberíamos dejar de trabajar y hacer herramientas?

Como ingeniero de software, siempre estamos ansiosos por obtener herramientas efectivas para aumentar nuestra productividad. Y en nuestro trabajo diario, a menudo no estamos satisfechos con las herramientas existentes y nos gustaría tener mejores formas, como una mejor configuración de script GDB, script Vim y algún script Python para hacer que las cosas aburridas sean automáticas.

Sin embargo, en realidad es una compensación, ya que la fabricación de herramientas también necesita tiempo y energía. No aumenta la productividad de inmediato. Por lo tanto, ¿cómo juzga si es hora de dejar de trabajar y hacer algunas herramientas para aliviar su dolor futuro?

Yo "hago herramientas" cuando uno de estos es cierto:

1. La tarea me está molestando
2. El riesgo de error humano en la tarea es demasiado grande.

El "riesgo" para la segunda opción no tiene que ser enorme: el costo de construir una herramienta pequeña generalmente es pequeño, por lo que si todo lo que ahorra es el riesgo de ejecutar una compilación de 10 minutos una vez por semana, generalmente pagarse muy rápido.

Trato de hacer que las herramientas sean lo más pequeñas posible, solo hacer la tarea un poco más fácil ahora y tal vez mejorar de nuevo la próxima vez.

Esto significa que solo reparas el mayor dolor cada vez, y no creas soluciones a problemas que realmente no te lastiman.

Con experiencia, he descubierto que simplemente presionar duro en el trabajo duro suele ser el más eficiente. Hacer una herramienta a menudo es tentador. Dejo de resistir cuando:

• La herramienta tiene más de un propósito. Un buen jugador de ajedrez logró dos cosas con cada movimiento: bloquear la pieza de un oponente y liberar un alfil. Un principiante probablemente necesitaría dos turnos para hacer eso. Del mismo modo, considero si la herramienta solo haría una cosa, o con un pequeño esfuerzo adicional hacer dos, por ejemplo, ayudar a corregir algunos archivos de datos en bruto y también crear datos de prueba artificiales.
• Utilidad futura. Puede ahorrarme tiempo para el trabajo de esta semana, pero ¿es probable que ahorre tiempo para mí o para alguien en un nuevo proyecto la próxima semana?
• Es un buen momento para aprender un nuevo idioma, biblioteca, técnica de diseño o lo que sea, y tengo tiempo para hacerlo. La herramienta es un efecto secundario beneficioso de hacer algo educativo, usando el tiempo ya otorgado para la educación.
• Cuando tenemos serios problemas para hacer que las cosas funcionen. Al igual que paracaidismo sin paracaídas, realmente debe tomarse el tiempo para hacer o comprar un paracaídas. Si no puede obtener resultados experimentales significativos, o la nueva aplicación web no funciona, simplemente debe detenerse y crear o comprar una herramienta para medir lo que no puede ver, manejar componentes o reemplazar parte del sistema. Cuando el trabajo está totalmente necesitado de una herramienta, no me importa el uso futuro o el uso múltiple. La necesidad pesa lo suficiente.

Mi regla general es que cuando tengo que hacer algo por tercera vez, es hora de escribir un pequeño script para automatizarlo o repensar mi enfoque.

No estoy haciendo una "herramienta" completa en este punto, solo un pequeño script (generalmente bash o python; perl también funcionaría, o incluso PHP) que automatiza lo que hice manualmente antes. Básicamente es una aplicación del principio DRY (o el principio Single Source Of Truth, que es esencialmente lo mismo): si tiene que cambiar dos archivos fuente en conjunto, debe haber alguna verdad común que compartan, y que la verdad tiene que ser factorizada y almacenada en un lugar central. Es genial si puedes resolver esto internamente refactorizando, pero a veces, esto no es factible, y ahí es donde entran los scripts personalizados.

Luego, más adelante, el guión puede o no evolucionar en una herramienta completa, pero generalmente comienzo con un guión muy específico con muchas cosas codificadas.

Odio el trabajo duro con pasión, pero también creo firmemente que es un signo de diseño incorrecto o malo. Ser perezoso es una cualidad importante en un programador, y es mejor que sea del tipo en el que pasas grandes distancias para evitar el trabajo repetitivo.

Claro, a veces el saldo es negativo: pasas tres horas refactorizando tu código o escribiendo un script para ahorrarte una hora de trabajo repetitivo; pero, por lo general, el balance es positivo, más aún si considera costos que no son directamente aparentes: falla humana (los humanos son realmente malos en el trabajo repetitivo), base de código más pequeña, mejor mantenibilidad debido a la redundancia reducida, mejor auto documentación, futuro más rápido desarrollo, código más limpio. Entonces, incluso si el saldo parece negativo en este momento, la base de código crecerá aún más, y esa herramienta que escribió para generar formularios web para tres objetos de datos seguirá funcionando cuando tenga treinta objetos de datos. En mi experiencia, el equilibrio generalmente se estima a favor del trabajo duro, probablemente porque las tareas repetitivas son más fáciles de estimar y, por lo tanto, se subestiman, mientras que la refactorización, la automatización y el resumen se perciben como menos predecibles y más peligrosos, y por lo tanto sobreestimados. Por lo general, resulta que la automatización no es tan difícil después de todo.

Y luego existe el riesgo de hacerlo demasiado tarde: es fácil refactorizar tres nuevas clases de objetos de datos en forma y escribir un script que genere formularios web para ellos, y una vez que lo haya hecho, es fácil agregar 27 clases más que También trabaje con su guión. Pero es casi imposible escribir ese script cuando ha llegado a un punto en el que hay 30 clases de objetos de datos, cada una con formularios web escritos a mano y sin ninguna coherencia entre ellos (también conocido como "crecimiento orgánico"). Mantener esas 30 clases con sus formas es una pesadilla de codificación repetitiva y reemplazo de búsqueda semi-manual, cambiar aspectos comunes lleva treinta veces más de lo debido, pero escribir un guión para resolver el problema, lo que habría sido una pausa para el almuerzo sin complicaciones cuando el proyecto comenzó ahora es un terrible proyecto de dos semanas con la perspectiva temible de un mes posterior que consiste en corregir errores, educar a los usuarios y posiblemente incluso darse por vencido y volver a antigua base de código. Irónicamente, escribir el desorden de la clase 30 tomó mucho más tiempo de lo que lo habría hecho la solución limpia, porque podrías haber estado usando el script conveniente todo ese tiempo. En mi experiencia, la automatización del trabajo repetitivo demasiado tarde es uno de los principales problemas en proyectos de software grandes de larga duración. porque podrías haber estado usando el conveniente guión todo ese tiempo. En mi experiencia, automatizar el trabajo repetitivo demasiado tarde es uno de los principales problemas en proyectos de software grandes de larga duración. porque podrías haber estado usando el conveniente guión todo ese tiempo. En mi experiencia, automatizar el trabajo repetitivo demasiado tarde es uno de los principales problemas en proyectos de software grandes de larga duración.

Acabo de recordar esto:

El problema con esto, por supuesto, es que en una situación de la vida real no puede medir fácilmente esos datos para seleccionar la celda correcta en la tabla. Y como se mencionó en otras respuestas, hay otras variables (el riesgo de error, la tarea es demasiado aburrida para hacerlo, incluso una vez, ...) necesita agregar a la ecuación.

Entonces, mi respuesta es que realmente depende de la situación y no puede esperar obtener una respuesta "correcta" para todas las situaciones. Después de todo, la vida sería aburrida si tuviéramos libros de cocina para todo.

Este es un gran problema en mi experiencia. La construcción de herramientas generalmente se deja a un desarrollador motivado que deja de trabajar para construir la herramienta. Esto a menudo interfiere con el desarrollo, incluso si proporciona valor. La construcción de herramientas debe verse como una parte integrada del "Proceso" de desarrollo.

Recuerdo haber asistido a revisiones de código donde los errores de encabezado resultarían en programar otra revisión. Muchos de estos podrían haber sido detectados por una herramienta. por ejemplo, conteos de sloc incorrectos, falta de requisitos, errores de formato Mi herramienta escrita en perl generó el encabezado del código entregado y los requisitos validados de una base de datos Oracle. No formaba parte de nuestro "Proceso", por lo que, a corto plazo, la construcción de la herramienta fue vista como un retraso en la entrega.

Todo el equipo necesita detenerse periódicamente y ver dónde hay esfuerzos manuales que pueden automatizarse mediante la creación de herramientas.

Todas las otras respuestas son buenas, pero agregaría una razón más por la que es valioso dedicar tiempo a crear herramientas pequeñas (y personalizar sus .vimrc, .emacs, etc.):

A veces, uno se queda "atrapado en la rutina" de forma creativa o motivadora y haciendo algo, cualquier cosa, "hará que los jugos fluyan" nuevamente (para mezclar metáforas). Idealmente, eso sería algo que impulse productivamente el proyecto, pero si es un poco tangencial y eso te inspira, entonces eso también es bueno.

Es posible que no esté mirando una pantalla en blanco, sino que simplemente tenga problemas para ver el progreso que está haciendo en una gran tarea. En esa situación, marcar algo tangible puede evitar que sienta que no va a llegar a ninguna parte.

Una variación de esto es cuando sigues pensando en algo que debería estar en el "segundo plano": solo tomarte un momento y hacerlo lo sacará de tu mente y te liberará para poner toda tu energía en la tarea principal nuevamente.

Depende de lo que consideres como hacer una herramienta. Podría decirse que hago muchos de ellos de maneras que otros desarrolladores considerarían frívolos ... Porque los hago para casi todo excepto los comandos más básicos del sistema de archivos.

Yo uso 2 fundamentos para apoyar eso.

• Es una extensión del principio DRY. Si queremos repetir algo, el esfuerzo manual es el uso menos efectivo de los recursos humanos.
• Es una forma efectiva de registrar lo que hice, por lo que si construí algo, entonces yo (u otra persona) podría querer referirme a cómo lo hice semanas o meses después y mantiene el registro del trabajo con el proyecto.

Ocasionalmente se convierten en herramientas más grandes y obtienen funciones interactivas, pero si no lo hacen, todavía tienen valor como registro.