¿Qué es una buena metáfora de programación? [cerrado]

Me refiero a explicarle al no programador qué es la programación. Me aseguré de buscar preguntas similares antes de crear esta, pero las pocas que encontré parecían esquivar la pregunta, y específicamente me gustaría ver algunas metáforas o analogías. Personalmente, me resulta más fácil explicarle algo técnico a alguien mediante el uso de metáforas o analogías.

La razón por la que estoy interesado en esto es porque muchas personas encuentran el trabajo de un programador a diario, pero si le preguntas a la persona promedio qué es o hace un programador, realmente no lo saben. Esto lleva a ciertas situaciones de malentendido (ej. "[...] ¡pero pensé que eras bueno con las computadoras!")

Realmente me gustaría encontrar el mejor por ahí. Me gustaría poder explicar fácilmente a alguien de qué se trata mi elección de carrera. Por supuesto, al menos la idea general.

Personalmente no tengo uno sólido, pero lo he pensado durante mucho tiempo y por lo general he gravitado hacia la metáfora del 'lenguaje', donde conocemos un lenguaje que las computadoras entienden y, por lo tanto, podemos decirle a las computadoras qué hacer, o "enseñarles", para resolver nuestros problemas.

Por ejemplo:

Imagine que en una realidad alternativa, existen robots humanoides con inteligencia artificial, y algunas personas pueden comunicarse con ellos a través de un idioma común, que es una variación del inglés. Estas personas que pueden comunicarse con los robots pueden enseñarles cómo resolver ciertos problemas o hacer ciertas tareas, como hacer nuestras tareas.

Bueno, aunque todavía no existen robots como ese, los programadores de nuestro tiempo son como esas personas, pero en lugar de comunicarse con los robots, se comunican con las computadoras. Los programadores "enseñan" a las computadoras cómo realizar ciertas tareas o resolver ciertos problemas mediante el software que crean utilizando este "lenguaje común".

Los programadores y este "lenguaje común" son los que nos brindan cosas como correo electrónico, sitios web, videojuegos, procesadores de texto, teléfonos inteligentes ( para decirlo simplemente ) y muchas otras cosas que usamos a diario.

No me refiero a poner la programación en el trono ni nada, es la mejor metáfora que se me ocurrió.

Estoy seguro de que alguien encontrará algún problema con este, probablemente sea un poco artificial, pero de nuevo por eso estoy haciendo esta pregunta.

Es como tener que escribir instrucciones detalladas paso a paso sobre cómo conducir en algún lugar. Pero generalmente tiene que agregar planes de contingencia para cosas como "qué pasa si hay un embotellamiento" o "qué pasa si un camión se descompone en el carril de giro".

Y a veces hay que sumergirse aún más y explicar las reglas de la carretera, como por qué lado conducir o qué hacer en un semáforo en rojo. Y a veces incluso necesita explicar con precisión cómo funciona el volante o el pedal del acelerador.

Y, por lo general, una vez que tiene todo lo que se describe con todo detalle, el cliente dice "eso es perfecto, excepto que debe funcionar para alguien que conduce un aerodeslizador"

Escribo instrucciones muy, muy detalladas para una máquina muy, muy tonta.

Utilizo la metáfora "Escribimos recetas de tejer ", que es amiga de la abuela.

Razón fundamental:

• El tejido de punto es un proceso mecánico bastante simple en el que básicamente debes seguir instrucciones detalladas exactamente para sacarle provecho.
• La mayoría de las instrucciones de tejido son para varios tamaños. Esto le da ifdeclaraciones y matemáticas y bucles.
• ¡Puedes encontrar el error en la receta cuando el ejército de abuelas enojadas viene con sus suéteres con errores!

No es una buena analogía, pero cuando la gente me dice que arregle su máquina, digo: "Soy el tipo que diseña los autos. ¡No soy el mecánico!"

Cuando era niño, leía una muy buena descripción de la programación: es como decirle a un robot cómo hacer una tarea común y cotidiana, como ir a la escuela. Entonces puedes decirle "¡Ve a la escuela!", Pero no sabe cómo. Entonces le dices que "salga, gire a la izquierda, siga caminando hasta llegar a la escuela, gire a la izquierda, entre y siéntese". ¡Pero hay un camino en el camino! Por lo tanto, debe decirle que "pare en el camino, verifique que no haya tráfico, cruce el camino y siga caminando" en algún lugar en el medio. ¿Y las puertas? Entonces agrega "verifique si la puerta de la escuela está abierta. Si no lo está, ábrala". ahí. Eventualmente, tienes un programa que puede decirle a tu robot cómo llegar a la escuela por sí mismo.

Esto encaja perfectamente con Logo, donde le das instrucciones a la tortuga exactamente de esta manera para crear formas complejas.

La programación es como una caja de bombones . A veces encuentras lo que estás buscando de inmediato, pero la mayoría de las veces lleva mucha prueba y error. A veces obtienes coco.

Semáforos . Los automóviles se mueven o se detienen. Es fácil imaginar un semáforo, pero ¿qué sucede si agrega otro? ¿Qué tal un tercio? ¿Qué tal una ciudad entera? Un sistema de tránsito está compuesto por miles de luces de freno, cada una simple en sí misma, pero cuando se toma como un todo, se convierte en un sistema complejo. Si uno de esos semáforos funciona mal o se apaga por solo unos segundos, arroja todo el sistema al caos. Si todo está sincronizado, simplemente disfruta el viaje.

Un orador motivacional encuentra claves para desbloquear el rompecabezas de las motivaciones, sueños e ideas de las personas. Cada situación, cada persona es diferente. Lo que funcionó en el pasado puede no ser apropiado ahora. A veces, una clave se puede reutilizar, pero debe adaptarse al individuo. Otras veces, la clave debe ser creada de nuevo. Lo más gratificante es cuando la persona ha sido desbloqueada y la ves salir y conquistar el mundo. Lo más devastador es cuando te sientes cerca, pero simplemente no eres capaz de desbloquear el potencial.

Una historia de detectives , donde el detective construye lentamente su caso buscando pistas y reuniendo evidencia. Metódico, inteligente y preciso ganará el día. Descuidado, ignorante y perezoso condenará el caso. Eventualmente, el trabajo se mantendrá o caerá ante un jurado de colegas.

Una máquina tragamonedas . Pones todas tus monedas y tiras de la palanca. A veces ganas a lo grande, a veces te sientas allí durante horas y no pasa nada. A veces alguien más pasa casualmente, tira de la palanca una vez y gana el premio gordo.

Música . Una nota es bastante simple, pero una medida es más compleja. Una canción completa tiene muchas medidas con muchas notas. Si una nota está desactivada, puede arruinar todo el rendimiento. Si cada nota se entrega perfectamente, la interpretación se desvanece en el fondo y solo existe la música.

La mejor metáfora de cualquier cosa es en sí misma. Cualquier cosa diferente perderá algo de precisión. Como tal, elegir la mejor metáfora depende de lo que, específicamente, desee capturar acerca de la programación. Dado que aquí se darán muchas respuestas sobre la codificación de metáforas, responderé con la metáfora clásica para el proceso de desarrollo en su conjunto:

Construcción de edificio

El aspecto más común de esta metáfora es que un arquitecto físico es algo análogo a un arquitecto de software. Aquí hay algunos otros paralelos:

• Los cambios son cada vez más baratos cuanto antes los realice. Es decir, puede mover una línea en papel ahora o 10 toneladas en cemento más adelante.
• Un edificio sin un plan adecuado tenderá a derrumbarse
• Los constructores intentan implementar lo que el cliente quiere. Si el cliente no describe con precisión cómo quiere que se vea el edificio (o si hay alguna otra falla en la comunicación), será costoso cambiarlo.
• Hay ciertas leyes de la física que no pueden doblarse. Así como una segunda historia de trescientos pies de ancho no se puede construir en una primera historia de 100 pies de ancho, la característica X no se puede construir sin un subsistema robusto Y.

Por supuesto, como cualquier metáfora, tiene sus limitaciones. Algunos defectos con esto:

• Los edificios son de uso único; lo construyes en alguna parte, y allí se queda. No puede copiarlo un millón de veces para un millón de usuarios diferentes con un millón de necesidades diferentes a un costo incremental cero.
• Los edificios son considerablemente más inmutables que el software.
• No existe una analogía clara con el costo del material de construcción. Una línea de código no cuesta nada, solo el tiempo que lleva producirlo cuesta dinero.
• La arquitectura incremental que es posible (dependiendo de a quién le pregunte) con el software no es posible con la construcción, donde la diseña una vez y luego la construye.

Entonces, como cualquier analogía, depende de lo que intentes explicar. Tenga cuidado de no confiar demasiado en ninguna metáfora, o su cliente comenzará a preguntarse cuáles serán los impuestos a la propiedad en su nuevo sistema de nómina.

Me encanta la analogía de Chris McMahon de que el desarrollo de software es como la creación de música, particularmente música de jazz.

Esta es Ella Fitzgerald y Count Basie haciendo la canción One O'Clock Jump. La canción es un blues de doce compases, que es el equivalente de jazz de una aplicación de base de datos con una interfaz de usuario. Lo que quiero decir es que, al igual que cada programador ha creado una aplicación de base de datos con una interfaz de usuario, cada músico estadounidense ha tocado blues de doce compases. Es un marco en el que se cuelgan muchas, muchas canciones, desde Count Basie hasta Jimi Hendrix y los Ramones.

Este video en particular es un gran ejemplo de práctica ágil. Escuche cómo la voz y el piano se influyen mutuamente. Esto se parece mucho a la programación de pares, y se parece mucho a TDD: la voz hace algo; el piano responde; el piano hace algo; La voz responde. Y observe el contacto visual. Estas personas son muy conscientes de lo que sucede instantáneamente. No tienen partituras (BDUF). Están involucrados en una actividad que requiere intensa concentración y habilidad, al igual que un buen desarrollo de software. También son claramente conscientes de que hay una audiencia, al igual que un buen desarrollo de software debe ser consciente de las necesidades de las personas que pagan las facturas.

Aquí está el enlace a la publicación del blog en el que lo discute: http://chrismcmahonsblog.blogspot.com/2007/05/example-of-analogy-monks-vs-music.html

A veces me refiero a la programación para controlar zombies sin sentido . Resumiendo mi publicación de blog al respecto:

• Al igual que los zombis, las computadoras con las que operamos son muy tontas. Es difícil instruirlos para que hagan algo a menos que las instrucciones estén detalladas
• El zombi es agresivo y si perdemos pequeños detalles en las instrucciones, dejamos a la criatura sin control, puede aplastar todo a su alrededor. Lo mismo con las computadoras: la falta de detalles en las instrucciones puede hacer que su programa se bloquee y destruya sus datos.
• Tienes que saber magia si quieres controlar a un zombie. Lo mismo con la programación.
• Cuantas más personas con cerebro se reúnen en un solo lugar, es probable que tengan más computadoras. Parece que los cerebros atraen las computadoras, de la misma manera que atraen a los zombis.

La programación es como construir cosas con Lego :

• Estás pegando muchas piezas pequeñas para hacer cosas más grandes
• Los pequeños trozos vienen en un número limitado de formas y tamaños.
• Las cosas pequeñas solo pueden encajar juntas de ciertas maneras
• Jugar con estas cosas puede ser muy divertido

Programar una computadora es como criar a un niño ...

• Todos no están de acuerdo en la forma correcta de hacerlo
• Te mantiene despierto por la noche
• Nunca hace lo que le dices
• No importa cuántos libros leas sobre el tema, cuando vayas a hacerlo, sientes que no tienes idea de lo que estás haciendo.
• Después de un tiempo, tiende a ser vago
• Espera que tenga grandes ganancias en el futuro, pero termina teniendo que mantenerlo hasta el final de su vida útil.
• Nunca es tan limpio, inteligente o seguro como quisieras que fuera
• Cuando lo miras más tarde, te preguntas qué diablos estabas pensando
• A pesar de todo el estrés que te ha causado, de todos modos te encanta.

La principal diferencia es que nos enojamos si alguien roba nuestro código fuente, pero a menudo nos alegra que alguien nos quite a nuestros hijos de nuestras manos.

La programación es como construir una fábrica o una línea de montaje.

Piense en el software como una máquina o línea de ensamblaje que existe dentro de la computadora. Algunas materias primas y componentes se alimentan a la máquina, y sigue un conjunto de procedimientos para procesarlos en algún producto final. Los procedimientos se configuran para realizar una operación específica en alguna materia prima o componente a un conjunto específico de parámetros (por ejemplo, tiempo, temperatura, distancia, etc.) en un orden particular. Si los detalles de la operación a realizar fueran incorrectos, o si los sensores de la máquina no estuvieran correctamente calibrados, o si alguna materia prima o componente no estuviera dentro de los estándares de calidad esperados, podría cambiar el resultado de la operación y el producto no resultaría como se esperaba.

Tal máquina es muy rígida en su funcionamiento e insumos aceptables. Las máquinas no cuestionan la inteligencia de los diseñadores ni su entorno operativo actual. Continuará siguiendo los procedimientos mientras se le indique. Incluso si un cambio en las materias primas o componentes pudiera tener un efecto drástico en lo que sucedió en operaciones posteriores, la máquina aún realizaría sus procedimientos. El proceso necesitaría ser revisado para ver qué cambios a los procedimientos fueron necesarios para compensar y producir el resultado deseado. Un cambio en el diseño o la configuración del producto también puede requerir un cambio significativo en las operaciones realizadas o en su pedido. Aunque los encargados de la producción aprendieron rápidamente la importancia de aislar las operaciones tanto como sea posible para reducir los efectos indeseables entre ellas, se hacen muchas suposiciones de la condición en que los componentes están en proceso de procesamiento; supuestos que podrían no detectarse hasta que el producto final esté en manos del usuario en un entorno operativo diferente.

Ayudar a un idiota rápido a pasar una clase de matemáticas que requiere un ensayo escrito.

La programación de computadoras es como jugar un juego de ajedrez en el que el tamaño del tablero, la cantidad de piezas en juego y las reglas que gobiernan esas piezas crecen en tamaño y complejidad a medida que avanza el juego.

Escribir software es como ... ¡Escribir! ^^

Los nuevos estudiantes de las clases de CS / Programación son, prácticamente, como usuarios sin programación. El ejemplo del robot es bueno.

En los años 80, usar Logo, Karel (o entornos de programación similares), donde el usuario aprende a programar, viendo la computadora como un robot, en lugar de un televisor con una máquina de escribir, ayudó mucho. Esas herramientas se utilizan comúnmente en la escuela secundaria y preparatoria.

¡Esa programación práctica ayudó a los estudiantes a adquirir habilidades para resolver problemas, incluso si no estaban relacionados con la computadora!

O, incluso si los estudiantes no se convirtieron en programadores.

Algunos colegas y universidades también aplicaron esas herramientas en los cursos de primer año.

Me pregunto por qué muchas escuelas secundarias dejan de enseñar Logo y Karel ...

Me gusta la analogía de Fred Brooks, de Mythical Man-Month, que la programación es como realizar magia.

(La) construcción del programa, a diferencia de las palabras del poeta, es real en el sentido de que se mueve y funciona, produciendo resultados visibles separados de la construcción misma. Imprime resultados, dibuja, produce sonidos, mueve los brazos. La magia del mito y la leyenda se ha hecho realidad en nuestro tiempo. Uno escribe el encantamiento correcto en un teclado, y una pantalla de visualización cobra vida, mostrando cosas que nunca fueron ni podrían ser. ...

(Uno) debe funcionar correctamente. La computadora también se parece a la magia del mito y la leyenda a este respecto. Si un personaje, una pausa del encantamiento no está estrictamente en forma adecuada, la magia no funciona. Los seres humanos no están acostumbrados a ser perfectos, y pocas áreas de actividad humana lo exigen. Adaptarme al requisito de perfección es, creo, la parte más difícil de aprender a programar.

"[...] ¡pero pensé que eras bueno con las computadoras!"

Esto suele ser un intento de engañar a un geek para que arregle una computadora (¿siente la necesidad de demostrar que está equivocado?). Mi respuesta estándar:
soy programador. Es como un ingeniero de automóviles: probablemente no sabrá cómo reparar los frenos de usted Trabant '72, y ciertamente no lo haría si lo supiera. ¡Un mecánico haría eso!

Soy aficionado al concepto de una receta para cocinar.

La programación es como manejar enormes cantidades de energía. Puedes hacer que la computadora haga lo que quieras. Solo está limitado por su imaginación y la cantidad de tiempo que está dispuesto a invertir.

Los programadores son como los fabricantes de una casa. Podemos contarte todo sobre las casas que hemos construido. Sin embargo, si nos pide que le preguntemos a una casa aleatoria por la que pasamos en el camino, es probable que no sepamos mucho. Pero si necesita agregar o cambiar algo en esa casa, podemos hacer que suceda siempre que el propietario nos lo permita.

En uno de los viejos artículos de Chris Crawford sobre programación , comparó un programa complejo con una burocracia, con múltiples agencias que se comunican pasando notas de ida y vuelta. He encontrado que es una metáfora muy útil al explicar el desarrollo de software.

Generalmente equiparo la programación a un rompecabezas.

Para crear un nuevo proyecto: tiene toneladas de piezas, algunas de las cuales no pertenecen a esta imagen, y no tiene una vista previa de cómo se ve el rompecabezas cuando está hecho. Pero sí conoce el tamaño y los colores generales, por lo que las estimaciones son posibles, pero no necesariamente precisas.

Para modificar un proyecto ya existente, apareció un gato y arrancó una parte del rompecabezas terminado. Tomará algún tiempo, pero el marco ya está allí, por lo que no debería ser tan malo (dependiendo de cuánto deba cambiarse).

También ayuda a describir el progreso. Uno de mis proyectos recientes, en un momento me preguntaba cómo describirlo para que una persona no técnica entienda por qué no sé cuánto tiempo más, y se me ocurrió: piense en un rompecabezas donde todos los Las piezas de borde están hechas, como son un poco más de la mitad si las piezas internas Los que quedan están separados entre sí, lo que tengo que hacer ahora es llenar los vacíos.

Es triste, pero la programación es un trabajo que solo se puede entender aprendiendo cómo hacerlo.

La programación tiene varios niveles diferentes de percepción y diferentes desde diferentes lados.

A bajo nivel es "escribir instrucciones muy, muy detalladas para una máquina muy, muy tonta"

En el siguiente nivel se trata de complejidad. Construyendo una nueva metáfora para simplificar el trabajo. Como las matemáticas superiores.

Desde un punto de vista diferente, el uso de tecnologías auxiliares como control de versiones, código auto documentado, construcción de proyectos y pruebas.

Desde el otro lado, está construyendo una interfaz de "usuario" (no literalmente, me refiero a la API también a la interfaz de usuario), predice posibles errores (realizados por el usuario, los datos o incluso él mismo) y corrige la reacción ante los errores.

Y finalmente.

La metáfora para la programación es literatura. Primero necesita aprender el alfabeto. Pero escribir una novela en esto incluso no comienza.