No importa c\u00f3mo se mire, en t\u00e9rminos generales los desarrolladores de software de aplicaciones empresariales tienen mala reputaci\u00f3n. Es casi inevitable que los sistemas se entreguen tarde o incluso no se entreguen. El usuario promedio en una empresa promedio pasar\u00e1 literalmente horas cada semana quej\u00e1ndose de los sistemas inform\u00e1ticos que se ve obligado a soportar. \u201c\u00bfPor qu\u00e9 hizo eso?\u201d, \u201c\u00bfQu\u00e9 diablos significa eso?\u201d son algunas de las cosas que escucho a diario. <\/p>\n\n\n\n\n\n\n\n
\n\t\tPas\u00e9 a\u00f1os escribiendo sistemas empresariales, en su mayor parte los usuarios eran positivos acerca de lo que obten\u00edan y usaban. Sistemas escritos seg\u00fan una especificaci\u00f3n inicial, probados hasta el final y luego adaptados cuando sea necesario a un costo acordado si es necesario. El apoyo continuo al cliente y los ingresos sostenidos para la empresa de software fueron una combinaci\u00f3n ganadora. La especificaci\u00f3n inicial basada en un an\u00e1lisis detallado de los requisitos siempre ser\u00eda una descripci\u00f3n general funcional y no contendr\u00eda ning\u00fan c\u00f3digo espec\u00edfico. Creo que us\u00e9 pseudoc\u00f3digo una vez (cuando estaba escribiendo juegos). "Esto es lo que necesitamos que haga", por lo general era suficiente para m\u00ed. Aparte de eso, fueron algunas maquetas de interfaz de usuario y mucho dise\u00f1o de base de datos y listo. La fase de prueba y "ajustes" del ciclo de vida del desarrollo fue muy importante. En general, los sistemas se entregaron a tiempo y funcionaron.\n\t\t<\/p>\n\n\n\n
\n\t\tHoy en d\u00eda (nunca pens\u00e9 que dir\u00eda eso), todo lo relacionado con los sistemas tiene que ver con planificaci\u00f3n, m\u00e1s planificaci\u00f3n y luego reutilizaci\u00f3n. Lo que me parece tan extra\u00f1o es que gran parte de esta planificaci\u00f3n no tiene como objetivo cumplir un requisito funcional sino m\u00e1s bien detallar c\u00f3mo y por qu\u00e9 vamos a escribir lo que escribimos cuando lo escribimos. \u00bfEspero que eso tenga sentido? \u00bfPor qu\u00e9 escribir algo en 10 l\u00edneas que podr\u00edas hacer en 1000 con la posibilidad de que \u201cquiz\u00e1s\u201d necesites reutilizarlo dentro de 2 a\u00f1os? A nivel personal nunca he escrito nada que no pudiera reescribir mejor 2 a\u00f1os despu\u00e9s. Siempre estoy aprendiendo y mejorando, cuando miro el c\u00f3digo, incluso cuando tiene 12 meses, a menudo me estremezco. Al mirar anuncios de empleo es f\u00e1cil perderse en las metodolog\u00edas y habilidades que se solicitan, \u00bfes humanamente posible que una persona sepa tanto?, me pregunto a menudo. Otra pregunta es: \u00bfalguna vez producen un producto? Con toda esta planificaci\u00f3n y preocupaci\u00f3n por reutilizar el c\u00f3digo, \u00bfalguna vez se hace algo? Conozco una empresa que contrat\u00f3 desarrolladores acad\u00e9micos que estaban tan ocupados concentr\u00e1ndose en el dise\u00f1o que la empresa quebr\u00f3 antes de que cualquier producto estuviera siquiera listo, \u00a1en serio! \u00a1Cu\u00e1ntos retrasos podemos esperar que tolere la gente, la fase de prueba nunca fue un problema all\u00ed! \u00bfPor qu\u00e9 deber\u00eda esperarse que la empresa que nos paga por un producto pague por un c\u00f3digo que se utilizar\u00e1 una y otra vez en proyectos posteriores y no para ellos?\n\t\t<\/p>\n\n\n\n
\n\t\tNo me malinterpretes, no digo que la planificaci\u00f3n sea mala, es una parte esencial del desarrollo de sistemas, pero no es la \u00fanica. Tal vez soy de la vieja escuela, pero lo que disfruto es escribir el sistema y hacerlo funcionar. Ok, s\u00e9 que los sistemas son cada vez m\u00e1s grandes y complejos. Los grandes equipos de desarrolladores son la norma. Es solo que creo que por mucho que planifiques, visualices y hagas una lluvia de ideas, siempre se perder\u00e1 algo. Nos esforzamos por conseguir sistemas imposibles y perfectos, pero en el peor de los casos no conseguimos ning\u00fan sistema. \u00bfNo me crees? Mire Microsoft. \u00bfImag\u00ednese las horas de trabajo que se dedican a planificar cualquiera de sus aplicaciones? \u00bfCon qu\u00e9 frecuencia se descubre un nuevo error o vulnerabilidad? \u00bfPor qu\u00e9 no se debatieron en la etapa de dise\u00f1o? Al equipo de desarrollo ni siquiera se le pas\u00f3 por la cabeza que pudiera ocurrir la "vulnerabilidad X". En pocas palabras, con algo m\u00e1s que el sistema m\u00e1s b\u00e1sico es casi imposible planificar todas las eventualidades, sin importar cu\u00e1n l\u00f3gico sea. \u00bfPor qu\u00e9 no se encuentran durante las pruebas? \u00bfLa soluci\u00f3n est\u00e1 aqu\u00ed en el desarrollo de la vieja escuela, menos tiempo para planificar (hablar), m\u00e1s tiempo para escribir y realizar pruebas? \u00bfMenos tiempo preocup\u00e1ndose por reutilizar el c\u00f3digo y m\u00e1s tiempo para darle al cliente un producto que funcione? \u00bfMicrosoft ser\u00eda mejor o peor si dedicaran menos tiempo a planificar y m\u00e1s a realizar pruebas? En defensa de Microsoft, son muy buenos parcheando, supongo que se podr\u00eda considerar que nos utilizan como evaluadores. \u00bfQuiz\u00e1s si dedicaran m\u00e1s tiempo a realizar las pruebas adecuadas no necesitar\u00edamos realizarlas?\n\t\t<\/p>\n\n\n\n
\n\t\tEl peor ejemplo de planificaci\u00f3n excesiva que todav\u00eda no he encontrado es un sistema financiero que uso a diario. La implementaci\u00f3n de este sistema cost\u00f3 millones de d\u00f3lares, a\u00f1os de planificaci\u00f3n y qui\u00e9n sabe cu\u00e1ntos consultores. Est\u00e1 escrito por uno de los actores m\u00e1s importantes de la industria del software, adaptado por una consultor\u00eda de software especializada. El resultado final de esto es un sistema que es pr\u00e1cticamente inutilizable y no muy lejos de ser reemplazado por un producto de venta libre. Es tan malo en el nivel m\u00e1s bajo que incluso un clic incorrecto del mouse bloquear\u00e1 la aplicaci\u00f3n. No puedo creer que este sistema haya sido probado antes de su entrega. Su entrega fue muy tard\u00eda, debido a que el \u201cciclo de planificaci\u00f3n\u201d fue m\u00e1s largo de lo esperado. Lo que hace no es tan complejo, es s\u00f3lo que obviamente ha sido planeado hasta el punto en que su implementaci\u00f3n ha sido un pensamiento apresurado. Toda esta planificaci\u00f3n ni siquiera ha resultado en un sistema que cumpla con los requisitos funcionales b\u00e1sicos de sus usuarios, pero je, estoy seguro de que reutilizar\u00e1n ese c\u00f3digo en alg\u00fan momento.\n\t\t<\/p>\n\n\n\n
\n\t\tDe todos modos, acabo de comenzar un diploma que me ayudar\u00e1 a comprender por qu\u00e9 es tan importante utilizar varias estrategias de planificaci\u00f3n diferentes. \u00bfPor qu\u00e9 escribir en 1 d\u00eda lo que podr\u00eda dedicar un mes a hacer \u201cbien\u201d? S\u00e9 que leer\u00e9 esto dentro de un par de a\u00f1os y me preguntar\u00e9 qu\u00e9 estaba pensando; O eso o me digo a m\u00ed mismo \u201cwow, ah\u00ed era cuando terminaba lo que estaba escribiendo\u201d. En serio, estoy seguro de que al final me dar\u00e9 cuenta de d\u00f3nde me estoy equivocando. Mientras tanto, seguir\u00e9 escribiendo aplicaciones usando mi estilo RAD (\u00a1me alegro de que tenga un nombre!) Aunque no es del gusto de todos, a m\u00ed me funciona bien. \n\t\t
<\/p>\n\n\n\n