Por qué los electricistas tienen autoridad y los desarrolladores no

8 min de lectura

Cuando la luz se enciende, la discusión termina

Un amigo me preguntó recientemente por qué los electricistas no sufren los mismos problemas que los desarrolladores de software. Un electricista hace una instalación, funciona o no, y eso es todo. Nadie intenta controlar narrativas sobre el trabajo eléctrico. Nadie programa reuniones para discutir si el cableado está “alineado con los objetivos del negocio”. Nadie contrata consultores para transformar la manera en que el electricista hace las conexiones.

Cuando se trata de software, todos tienen opiniones. Gerentes de proyecto, ejecutivos, stakeholders a tres niveles del trabajo, ese tipo de marketing que una vez construyó un sitio en WordPress. Todos se sienten calificados para opinar sobre cómo debe hacerse el trabajo.

¿Por qué la diferencia?

El regalo de la objetividad

El trabajo eléctrico disfruta de algo que el desarrollo de software necesita desesperadamente: estados objetivos de éxito o fracaso.

O el circuito está cableado correctamente o no lo está. O la luz se enciende o no. O el interruptor dispara cuando debe o no. No hay reunión para discutir si la luz está “suficientemente encendida” o si el circuito está “alineado con la visión estratégica”.

Los estándares están codificados en ley. Códigos de colores, tipos de cable, tamaños de interruptores, requisitos de conexión a tierra, esquemas de protección — todo documentado, probado y aplicado. Los inspectores verifican el cumplimiento contra criterios explícitos. La variabilidad de requisitos es pequeña. Un circuito de 20 amperios alimentando tomacorrientes de cocina es un circuito de 20 amperios alimentando tomacorrientes de cocina. El electricista no escucha a mitad del trabajo: “en realidad, decidimos que también debería hacer café”.

Esta objetividad da a los electricistas algo precioso: autoridad. Cuando el electricista dice “eso no cumple con el código”, la conversación termina. No hay negociación, no hay interpretación alternativa, no hay sesión de alineación con stakeholders. El código es el código.

La maldición de la subjetividad

El desarrollo de software opera en un universo diferente. Los requisitos son difusos, cambian constantemente y a menudo son internamente contradictorios. Un stakeholder quiere velocidad, otro quiere estabilidad, un tercero quiere funcionalidades que conflictúan con ambas. El documento de requisitos — si existe — estaba desactualizado antes de que se secara la tinta.

¿Qué significa éxito siquiera? “Suficientemente rápido.” ¿Suficientemente rápido para quién? ¿Bajo qué carga? ¿En qué hardware? “Suficientemente bueno.” ¿Suficientemente bueno comparado con qué? “Mantenible.” ¿Por qué equipo futuro con qué habilidades desconocidas?

No hay un código de normas universalmente aplicable. Claro, hay estándares — convenciones de código, guías de seguridad, patrones arquitectónicos — pero ninguno tiene peso legal. Nadie inspecciona tu repositorio y emite citaciones.

Aquí es donde empeora: todos usan software diariamente. Tu CEO usa un iPhone. Tu directora de marketing usa Slack. Los miembros de tu junta usan email. Esta familiaridad crea una ilusión de entendimiento. Usar una app hace que la gente crea que entiende cómo se construye. Es como creer que entiendes ingeniería automotriz porque conduces un auto.

El costo de los errores de software a menudo es retrasado, invisible o transferido. ¿Ese atajo arquitectónico tomado para cumplir una fecha límite? No dolerá hasta dieciocho meses después cuando el equipo intente agregar una funcionalidad. ¿La vulnerabilidad de seguridad? Silenciosa hasta que sea explotada. ¿La deuda técnica? Acumulando intereses en segundo plano, pagadera por algún desarrollador futuro que no estuvo en la sala cuando se tomaron las decisiones.

El problema de la visibilidad

Cuando un electricista termina el trabajo, puedes verlo. Los cables terminan en cajas. Los conductos corren por las paredes. Los interruptores están en tableros con etiquetas. Un no-electricista puede no entender los detalles, pero puede observar que se hizo trabajo y captar aproximadamente qué hace.

El desarrollo de software produce artefactos invisibles. El código vive en repositorios que los stakeholders nunca visitan. La arquitectura existe como cajas y flechas en diagramas que aproximan la realidad. El trabajo real — la lógica, las estructuras de datos, el manejo de errores, los casos límite — está oculto a la vista.

Esta invisibilidad crea un vacío que las narrativas llenan. Cuando no puedes ver el trabajo, necesitas que alguien te cuente sobre él. Y una vez que necesitas historias sobre el trabajo, has abierto la puerta a historias competidoras. De repente todos tienen una narrativa. La narrativa del deadline. La narrativa de la deuda técnica. La narrativa de “solo necesitamos esforzarnos más”. La narrativa de “los desarrolladores son muy lentos”.

No puedes señalar código como señalas una caja de conexiones y decir “mira, eso es lo que construimos, ahí estamos”. El estado del software siempre está mediado por la interpretación.

El vacío de poder

La combinación de subjetividad e invisibilidad crea un vacío de poder — y los vacíos de poder se llenan.

Si nadie puede verificar objetivamente si el software es “bueno”, entonces quien controla la narrativa controla la percepción de calidad. Los stakeholders quieren control porque el software afecta su dominio. Marketing quiere funcionalidades que apoyen campañas. Ventas quiere funcionalidades que cierren tratos. Finanzas quiere predictibilidad. Operaciones quiere estabilidad.

Ninguno de estos stakeholders puede evaluar el trabajo técnico directamente. Pero pueden evaluar narrativas. Pueden juzgar si el proyecto “parece” ir bien. Pueden evaluar si los desarrolladores parecen “receptivos” a las necesidades del negocio.

Por eso tanto desarrollo de software se convierte en performance. Las reuniones de estado no son sobre estado — son sobre controlar la percepción. Los demos no son sobre funcionalidad — son sobre crear confianza. Las métricas de velocidad no son sobre medir productividad — son sobre proporcionar algo contable para poner en diapositivas.

Lo que los electricistas no enfrentan

Los electricistas no enfrentan frameworks de gestión. Nadie implementa Scrum para instalaciones eléctricas. Nadie pregunta al electricista cuántos tomacorrientes puede instalar en un sprint de dos semanas y luego rastrea la velocidad en el tiempo. Nadie reestructura la empresa de contratistas eléctricos en tribus y squads.

Los electricistas no enfrentan ciclos de moda. No hay un circuito de líderes de pensamiento abogando que debemos repensar fundamentalmente cómo los cables se conectan a los terminales. Nadie vende certificaciones en el último enfoque revolucionario para instalar conductos. El trabajo cambia cuando la tecnología cambia — cuando LED reemplazó a las incandescentes, cuando surgieron los sistemas de hogar inteligente — no porque alguien necesitaba un contrato de libro. Como exploré en Frameworks de Gestión y la Proximidad al Aceite de Serpiente, las estructuras de incentivos en la consultoría de software favorecen la venta de procesos sobre resultados verificables.

Los electricistas no enfrentan la suposición de que la velocidad requiere atajos. Cuando un edificio necesita trabajo eléctrico más rápido, contratas más electricistas o pagas horas extra. No pides a los electricistas existentes que omitan la conexión a tierra o usen cable más delgado. El código no lo permite. El inspector no lo aprobará. El edificio no funcionará de manera segura sin ello.

La ruta de escape

¿Qué puede aprender el desarrollo de software del trabajo eléctrico? No todo se transfiere — el software genuinamente es más complejo y variable — pero algunas cosas sí.

Crear señales objetivas. Integración continua que pasa o falla. Pruebas automatizadas que se ejecutan o rompen. Pipelines de despliegue que entregan software funcionando o no. Estos no son perfectos — aún requieren juicio sobre qué probar y medir — pero son más objetivos que reuniones de estado y votos de confianza.

Hacer el trabajo visible. No a través de diapositivas e informes — a través de software funcionando. Desplegar frecuentemente para que los stakeholders puedan ver qué existe, no solo escuchar sobre ello. Cuando la funcionalidad corre en producción, la competencia de narrativas termina. O los usuarios pueden hacer la cosa o no pueden.

Codificar estándares. Estándares internos de código, registros de decisiones arquitectónicas, requisitos de seguridad con cumplimiento automatizado. Estos no tendrán peso legal, pero establecen expectativas que reducen el espacio para la interpretación.

Reconocer lo que no se puede arreglar. Algo de subjetividad es inherente al software. Los requisitos cambiarán porque el mundo cambia. Los criterios de éxito seguirán siendo difusos porque los negocios operan en entornos difusos. No puedes eliminar esto — solo puedes dejar de pretender que no existe. La incertidumbre honesta es mejor que la precisión falsa.

La diferencia central

El trabajo eléctrico permanece basado en hechos, verificable y no afectado por la moda o los frameworks de gestión. La luz se enciende. El circuito está protegido. La etiqueta de conformidad va en el tablero.

El desarrollo de software se vuelve basado en narrativas porque el trabajo es invisible. Plagado de opiniones porque la calidad es difícil de juzgar temprano. Controlado por la gerencia porque a menudo falta disciplina de ingeniería medible.

La próxima vez que alguien pregunte por qué los desarrolladores enfrentan interferencia que los electricistas no tienen, tienes la respuesta: los electricistas trabajan con realidad objetiva. Los desarrolladores trabajan en un vacío narrativo que todos quieren llenar.

La solución no es convertirse en electricistas — el software genuinamente es diferente. La solución es crear suficientes señales objetivas para que el vacío narrativo se reduzca. Cuando el pipeline de despliegue está verde, cuando las métricas de producción muestran usuarios completando sus tareas, cuando el código pasa todas las verificaciones automatizadas — esos se convierten en los hechos que limitan cuánta opinión puede entrometerse.

No todas las discusiones terminarán. Pero algunas sí. Y eso es un comienzo.