Los desarrolladores de sistemas comerciales tienen un mal nombre
Agile, Scrum, palabras sofisticadas para escribir software que cumpla
No importa de qué manera lo mires, en términos generales, los desarrolladores de software de aplicaciones comerciales tienen una mala reputación. Los sistemas se entregan casi inevitablemente tarde o incluso no se entregan. El usuario promedio en la empresa promedio pasará literalmente horas cada semana quejándose de los sistemas informáticos que se ven obligados a soportar. "¿Por qué ha hecho eso?", "¿Qué diablos significa eso?" son algunas de las cosas que escucho a diario.
Pasé años escribiendo sistemas comerciales, en su mayor parte los usuarios eran positivos acerca de lo que estaban obteniendo y usando. Sistemas escritos según una especificación inicial, probados hasta el final y luego adaptados cuando sea necesario a un costo acordado si es necesario. El apoyo continuo para el cliente y los ingresos sostenidos para la empresa de software fueron una combinación ganadora. La especificación inicial basada en un análisis de requisitos detallado siempre sería una descripción general funcional y no contendría ningún código específico, creo que usé pseudocódigo una vez (cuando estaba escribiendo juegos). "Esto es lo que necesitamos que haga", por lo general era lo suficientemente bueno para mí. Aparte de eso, hubo algunas maquetas de interfaz de usuario y mucho diseño de base de datos y listo. La fase de prueba y 'ajuste' del ciclo de vida del desarrollo fue muy importante. En general, los sistemas se entregaron a tiempo y funcionaron.
En estos días (nunca pensé que diría eso), todo lo relacionado con los sistemas tiene que ver con la planificación, más planificación y luego la reutilización. Lo que me parece tan extraño es que gran parte de esta planificación no es para cumplir con un requisito funcional sino para detallar cómo y por qué vamos a escribir lo que escribimos cuando lo escribimos. ¿Espero que tenga sentido? ¿Por qué escribir algo en 10 líneas que podría hacer en 1000 con la posibilidad de que "podría" necesitar reutilizarlo 2 años después? A nivel personal nunca he escrito nada que no pudiera reescribir mejor 2 años después. Siempre estoy aprendiendo y mejorando, cuando miro hacia atrás en el código, incluso de 12 meses, a menudo me estremezco. Mirando anuncios de trabajo es fácil perderse en las metodologías y habilidades que se piden, ¿es humanamente posible que una persona sepa tanto como yo a menudo me pregunto? Otra pregunta es ¿alguna vez producen un producto? Con toda esta planificación y preocupación por reutilizar el código, ¿alguna vez se hace algo? Sé de una empresa que contrató a desarrolladores académicos que estaban tan ocupados concentrándose en el diseño que la empresa quebró antes de que cualquier producto estuviera siquiera cerca de estar listo, ¡en serio! ¡Cuántos retrasos podemos esperar que la gente tolere, la fase de prueba nunca fue un problema allí! ¿Por qué debería esperarse que la empresa que nos paga por un producto pague por un código que se usará una y otra vez en proyectos posteriores que no son para ellos?
No me malinterpreten, no digo que la planificación sea mala, es una parte esencial del desarrollo de sistemas, pero no es la única parte. Tal vez soy de la vieja escuela, pero la parte que disfruto es escribir el sistema y hacer que funcione. Ok, sé que los sistemas son cada vez más grandes y complejos. Los grandes equipos de desarrolladores son la norma. Es solo que creo que no importa cuánto planees, visualices y hagas una lluvia de ideas, siempre se perderá algo. Nos esforzamos por lo imposible, los sistemas perfectos, pero en el peor de los casos, en realidad no estamos entregando ningún sistema. ¿No me crees? Mira Microsoft. ¿Imagínese las horas de trabajo que se dedican a planificar cualquiera de sus aplicaciones? ¿Con qué frecuencia se descubre un nuevo error o vulnerabilidad? ¿Por qué no se discutieron en la etapa de diseño? Ni siquiera pasó por la mente del equipo de desarrollo que la "vulnerabilidad X" podría ocurrir. En pocas palabras, con algo más que el más básico de los sistemas es casi imposible planificar todas las eventualidades sin importar cuán lógico sea. ¿Cómo es que no se encuentran durante las pruebas? ¿La solución aquí es el desarrollo de la vieja escuela, menos tiempo para planificar (hablar), más tiempo para escribir y probar? ¿Menos tiempo preocupándose por reutilizar el código y más tiempo dándole al cliente un producto funcional? ¿Microsoft sería mejor o peor si dedicara menos tiempo a la planificación y más tiempo a las pruebas? En defensa de Microsoft, son muy buenos parcheando, supongo que se podría considerar que nos usan como probadores. ¿Quizás si pasaran más tiempo haciendo las pruebas adecuadas, no necesitaríamos probar para ellos?
El peor ejemplo de planificación excesiva que aún no he encontrado es un sistema financiero que uso a diario. La implementación de este sistema costó millones de dólares, años de planificación y quién sabe cuántos consultores. Está escrito por uno de los jugadores más importantes de la industria del software, adaptado por una consultora de software especializada. El resultado final de esto es un sistema que es prácticamente inutilizable y no muy lejos de ser reemplazado por un producto estándar. Es tan malo en el nivel más bajo que incluso un clic del mouse en el lugar equivocado colgará la aplicación. No puedo creer que este sistema haya sido probado antes de entregarlo. Se retrasó mucho en la entrega tal como estaba, debido a que el "ciclo de planificación" fue más largo de lo esperado. Lo que hace no es tan complejo, es solo que obviamente ha sido planeado hasta el punto en que la implementación ha sido una idea apresurada. Toda esta planificación ni siquiera ha dado como resultado un sistema que cumpla con los requisitos funcionales básicos de sus usuarios, pero estoy seguro de que reutilizarán ese código en algún momento.
De todos modos, acabo de comenzar un diplomado para ayudarme a comprender por qué es tan importante usar varias estrategias de planificación diferentes. ¿Por qué escribir en 1 día lo que podría pasar un mes haciendo “bien”? Sé que leeré esto en un par de años y me preguntaré qué estaba pensando; o eso o me digo a mí mismo "wow, ahí es cuando en realidad solía terminar lo que estaba escribiendo". Hablando en serio, estoy seguro de que al final me daré cuenta de dónde me estoy equivocando, mientras tanto seguiré escribiendo aplicaciones usando mi estilo RAD (¡me alegro de que tenga un nombre!) que aunque no es del gusto de todos, a mi me funciona bien.
nb ¿Quién lo hubiera adivinado? Mi enfoque de desarrollo tiene un nombre, ¡está clasificado como Metodología Ágil! Aquí hay un excelente artículo que explica Metodologías ágiles en algún detalle.