Los ingeniero de software son siempre curiosos, entusiastas y animados a hacer todas las cosas. Al menos al principio. En el camino, estos cabezotas se enfrentan con un mundo que definitivamente no entiende sobre el desarrollo de software, sistemas que cuentan ingenieros por números, productividad por líneas de código y calidad de procesos; un mundo donde el desarrollo de software está manejado por una burocracia que maneja riesgos más que un consejo creativo que pueda resolver los problemas de los clientes.
Desafortunadamente, muchos ingenieros consideran esto una llamada para despertar y adoptar esas formas burocráticas, convencidos que han aterrizado en un nuevo y adulto mundo de la administración. Alguien que administre resistir a dar un mal paso y no caiga en las tentaciones del martirio, ya que cada fallo es algo que la administración hizo o no hizo.
Si eres un ingeniero de software o un jefe de ingenieros, a continuación tenemos una lista para ayudarte a identificar si sigues con tus genes de desarrollo de software activos o te has convertido en alguien que dicta clichés de forma robótica en cada reunión, asesinando cada idea y la moral detrás de ella:
10. "Esto es suficientemente bueno" : El hecho es que nada es suficientemente bueno, al menos para cualquier software. Puede ser suficientemente bueno para hoy, o para esta versión, pero si tu producto ha tenido el mismo problema la última década, alguna empresa de la competencia ya se ha llevado a tus clientes por ello. Repáralo antes que llegues al punto donde no puedas.
9. "Esta es la forma en que siempre lo hemos hecho": Esto es un anacronismo en cualquier campo competitivo y rápidamente cambiante. Especialmente en el software. Las empresas de software no son como empresas fabricantes de autos que pueden ensamblar cualquier línea y olvidarse de ella por unos cien años. ¡Espera un minuto! Ni siquiera las empresas fabricantes de autos hacen eso. Los problemas de hoy requieren un nuevo conjunto de soluciones porque en una industria que funciona bajo algo como las Leyes de Moore, junto con las expectativas de las personas, hay un estado permanente de cambio.
8. "Hay suficiente tiempo para hacerlo bien": Esto es la forma en que acabas en deuda técnica. De alguna forma es inevitable debido a las presiones del negocio o trabajar con una nueva pieza de hardware o tecnología. Tanto como vas pagando tu deuda en el futuro inmediato, esto es parte del proceso, pero si evitas hacer las decisiones correctas y la responsabilidad va con eso, no vas a ser consecuente con tus principios de ingeniero de software.
7. "Esto requiere cambios arquitecturales profundos": ¿Qué cosa no las necesita? Idealmente, una pieza bien diseñada de software debería ser flexible a los cambios mientras el producto se va desarrollando. Pero como nosotros dijimos, la demanda en el software cambia rápidamente y cada pieza de software escrita necesita ser volver a ser escrita. Esta es la naturaleza del trabajo, no una anomalía para ser utilizada como una excusa.
6. "La Administración no lo ha priorizado": ¿Acaso la administración no ha priorizado hacer un buen producto? ¿libre de errores? ¿sin código mal escrito? ¿que hace al cliente feliz? De acuerdo, algunas veces heredamos código y tendremos que lidiar entre reparar lo que ya está hecho y escribir nuevo código pero ese es un argumento poco válido como veremos a continuación. Es suficiente decir que la ingeniería necesita configurar y ejecutar sus propias prioridades, aunque sean pequeñas, cada día, en vez de esperar por algún mandato superior y mágico, ya que eso no va a suceder.
5. "Hay mucho en nuestro plato": Esta es una de las tautologías sin sentido que no añade nada a la discusión. El foco no es más la idea o como debería ser ejecutada sino “no tenemos recursos” o la enorme lista de errores presentada por el cliente. Por supuesto que tienes mucho en tu plato, ya que te pagan por tener eso en tu plato, empieza a comer.
Si una idea vale ser ejecutada, su adopción no debería depender si tienes o no mucho en tu plato, si llenas tu plato en el buffet con basura y decides que no tienes el plato deseado porque tu plato está lleno, ya has hecho dos cosas mal: elegiste malas cosas para empezar y no tienes que hacer muchos cálculos para saber que tienes que tirar la basura y conseguir lo que quieres. No mates la idea, limpia el plato.
4. "Nuestro software es muy completo, tenemos que tener cuidado si hacemos cambios": Esta es otra tautología sin sentido. ¿Qué software empresarial no es complejo? ¿Estás diciendo que no eres usualmente poco cuidadoso cuando escribes código? Eres un ingeniero de software, y debes esperar lidiar con la complejidad y ser cuidadoso cuando haces cambios, es un requerimiento básico. Si esta fuera una razón por la que los ingenieros no pueden ejecutar una idea, deberíamos aprender nuevamente lo básico.
3. "Nadie está pidiendo eso": Esto puede hacer recordar a un comentario que hizo Henry Ford: “si le preguntara a la gente, lo que ellos quieren, ellos dirán que quieren un caballo más rápido”. Los seres humanos son increíblemente adaptables, ellos vivirían con cualquier cosa, incluyendo como dijo Ford, caballos más rápidos. Si le das a tus clientes un producto por debajo de los estándares, ellos vivirán con eso. Pero recuerda que los humanos también somos increíblemente cambiantes, una idea que mates o que tengas encerrada, crecerá en otra empresa. Si somos descuidados porque creemos que nuestro software es “pegajoso” (es decir que los clientes nos odian pero no pueden cambiar porque es mucho trabajo), estamos fijando nuestro techo en un nivel que no vale para un verdadero ingeniero.
2. "Tenemos consensos": Esto parecería una afirmación inocua con noble intención, pero es insidiosa y fijándonos bien, no tienen ningún significado en el contexto del software. El consenso tiene una indebida importancia en todo desde reuniones de diseño, revisiones de SRS/SDS, documentación, prácticas de QA, etc. El desarrollo de software es un ejercicio de conducción por expertos. Alguien que ha pasado años estudiando, aprendiendo y trabajando en un campo específico, y no apartas a esa persona para la decisión final arrojando toda esa experiencia, sin mencionar que puedes entregar un mal producto, desmoralizar al experto, y adoptar la forma más segura y más tímida y más insidiosa de todas, la contabilidad difusa.
Una decisión de grupo es una forma de evadir la responsabilidad por el producto. “Lo decidimos todos”, es una forma de decir: “nadie es responsable”. En un sistema presidencial de gobierno, el congreso recomienda al presidente pero el presidente es el que toma la decisión. A menos que la decisión del presidente sean obviamente horrenda que la mayoría del congreso decida vetar la decisión, esta queda.
1. "No puede ser hecho": No hay nada que no pueda ser hecho en software. Los chicos no ingenieros te rodean diciendo “es solo software, cierto” como una forma gentil de provocar a los ingenieros ¡pero es verdad! Es esencialmente solo software. Los ingenieros debería responder especificando lo que toma implementar más que decir que no puede ser hecho. Deberíamos decir “tomará 3 ingenieros, con licencias para XYZ, cinco computadoras con el procesador DFE, con 2 TB de almacenamiento, y 8 meses para hacer ese software”, en vez de “no puede hacerse”.
Todo puede ser hecho, fijemos eso en nuestra mente primero. El resto caerá por su propio peso.
