Check the new version here

Popular channels

Quieres ser programador? disfruta desperdiciando tu vida.

Alex’s Soapbox: Programar es una mierda! O como mínimo debería serlo.


Programar no es divertido. Es aburrido, tedioso y desde luego no supone un desafío. Y no importa cómo intentes verlo, definitivamente no es sexy.


Sé lo que estás pensando. Cualquiera que diga esto -o lo bloguee- debería ser inmediatamente desposeído de su carnet de desarrollador, de su teclado y permitírsele usar únicamente CP/M con discos de 8” y modems de 1200 bpm.

Obviamente, muchos de nosotros -me incluyo- disfrutamos programando. Pero ¿deberíamos hacerlo?

¿Por qué escribimos código?

El desarrollo de software es una profesión única en la que utilizar nuestras habilidades tanto en el trabajo como en nuestro tiempo de ocio. Al contrario que los contables, que no van corriendo del trabajo a casa para cuadrar el presupuesto familiar, la mayoría de nosotros trasteamos con el código por diversión.

Consideremos al que no programa por afición y el trabajo que realiza. De hecho, concretemos un poco más, consideremos a los programadores del software “aburrido”. Por “aburrido” me refiero a facturas, utilización y monitorización de flotas, creación de informes de gastos, etc … software de uso interno con muchísimos requerimientos específicos de una compañía en concreto. Por ello, reitero el hecho de que si no tiras líneas de software “aburrido” para ganarte la vida, este artículo no va dirigido a tí.



Quizás la línea entre “aburrido” y “sexy” puede ser borrosa a veces, te lo explicaré, el software sexy representa el tipo de aplicaciones que utilizamos cada día: SVN, Google maps, Visual Studio, Firefox, etc. De hecho, como desarrolladores nosotros casi nunca utilizamos software aburrido.

Desde una perspectiva de desarrollador, los porcentajes se invierten. Sólamente a unos cuantos privilegiados se les paga para desarrollar software sexy, mientras que la mayoría de nosotros
estamos anclados en el desarrollo de la parte aburrida del software.


Características básicas del software aburrido

Existe una nomenclatura para ese tipo de software aburrido: los sistemas de información. A pesar de que los propósitos de los sistemas de información y los requerimientos específicos cambian de
una compañía a otra, en el fondo son esencialmente lo mismo. Tenemos una base de datos que
modeliza el mundo real, reglas que definen cómo pueden cambiar los datos, un interfaz con la base
de datos, y un montón de informes diferentes.

El proceso formal de creación de estos sistemas data de la década de los ’60 y no ha cambiado
demasiado desde los ’70 (el análisis de estructuras sigue siendo sorprendentemente moderno).
Esencialmente, analizas el problema, mapeas el flujo de datos, lo estructuras, creas la base de
datos y desarrollas programas que acceden a ella y la modifican.




Hemos pasado de los clientes ligeros sobre pantallas verdes a clientes pesados sobre PC’s.
Entonces pasamos a clientes ligeros sobre web y ahora con plataformas como Windows Presentation
Foundation, volveremos a clientes pesados en muy poco tiempo. De todas formas, todos los sistemas
siguen haciendo lo mismo: entrardatos, mostrardatos.

El desarrollo de sistemas de información tampoco ha cambiado demasiado. Da lo mismo si usas Visual Basic 3.0 o XHTML, el concepto es prácticamente el mismo: la base de datos tiene que mostrarse al usuario de una manera amigable. El código para conseguirlo, es y siempre lo ha sido, bastante tedioso:


txtFirstName.DisplayWidth = 30;
txtFirstName.MaxCharLength = 50;
SetTextBoxValidator(txtFirstName, Validations.LettersOnly);
txtFirstName.Enabled = securityContext.CanEdit;
txtFirstName.Value = customerRecord.FirstName;


Esas cinco líneas de código sólamente para inicializar algunas propiedades del interfaz de usuario (UI). Multiplícalo por cada campo, para cada entidad y después por 1.5, porque algunos campos tienen que ser accesibles en dos sitios distintos. Ahora añade todo el código necesario para validar y guardar los datos desde el UI. Si las matemáticas no me fallan, eso no hace más que generar basura en un código aburrido.

El dilema del desarrollador

“Tedioso” y “aburrido” son dos palabras que no encajan bien con los programadores.


Somos gente analítica y a menudo tenemos una licenciatura en Informática. Y es que somos capaces de mucho más que atar la capa de presentación y de servidor usando una línea de código detrás de otra. Quizás deberíamos ser capaces de usar nuestras habilidades y capacidad para hacernos más fácil el trabajo.

Y ahí está el problema. Como dijo Michael A. Jackson en 1975 Principles of Program Design, “los programadores a menudo se refugian en un inclinación comprensible, aunque desastrosa, hacia la complejidad y la ingenuidad en su trabajo. Como se les prohíbe diseñar nada más grande que un programa, responden haciendo ese programa suficientemente complicado para desafiar su profesionalidad”


Esta observación de hace 35 años Nota del traductor: casi 40 se confirma cada día en TDWF. Parte del código más atroz e historias aquí escritas se derivan del deseo de los desarrolladores por demostrar su inteligencia. LLevar a cabo esos deseos no tiene una naturaleza maliciosa ni retorcida, sino meramente instintiva.

Cuando escribí sobre Codificación suave Nota del traductor: Soft Coding, presenté un fragmento de código de negocios para ilustrar lo que la mayoría de código debería tener en común: es decir, código muy específico para implementar requisitos de negocio muy específicos. Es bastante aburrido:


private void attachSupplementalDocuments()
{
if (stateCode == "AZ" || stateCode == "TX" {
//SR008-04X/I are always required in these states
attachDocument("SR008-04X";
attachDocument("SR008-04XI";
}

if (ledgerAmnt >= 500000) {
//Ledger of 500K or more requires AUTHLDG-1A
attachDocument(“AUTHLDG-1A”);
}

if (coInsuredCount >= 5 && orgStatusCode != “CORP”) {
//Non-CORP orgs with 5 or more co-ins require AUTHCNS-1A
attachDocument(“AUTHCNS-1A”);
}
}


En las numerosas respuestas al artículo, algunas personas ofrecen algunos comentarios de bastante buen humor, demostrando maneras en las que el código podría ser “complejizado”. Estos ejemplos fueron, por desgracia, bastante representativos de lo que he encontrado realmente en respuesta a los requerimientos del negocio simples .

Otros ofrecieron algunas sugerencias de refactorización graves relacionadas con todo tipo de patrones de diseño, interfaces, suplementadores, y un montón de clases. Naturalmente, todo ello sin haber visto nunca el módulo en el que el código hipotético residía, por no hablar de que carecían de una amplia comprensión de todo el sistema y sus requisitos.

Y luego estaba este chico, James Taylor, que básicamente me llamó idiota por sugerir que los programadores se ensucian las manos con las reglas de negocio. Al parecer, deberíamos construir sistemas expertos con fantásticos interfaces de usuario destelleantes que permitan al usuario final hacer todo el trabajo sucio.


Por supuesto, los que tenemos los pies en el suelo entendemos que tales sistemas expertos sólo existen en la tierra de polvo de hadas, los unicornios, y la compresión sin pérdida de datos aleatorios. Pero hay otra realidad que todavía muchos de nosotros tenemos que aceptar: el desarrollo de aplicaciones es una mierda, y ninguna cantidad de patrones XML o de diseño va a cambiar esto.


Es una mierda y punto.


No es fácil conciliar el hecho de que el software se escribe cada día es, a pesar de todos los intentos y propósitos, abrumadoramente aburrido. Gestión de suscripciones a revistas. Informes de facturación médica. Gestión del inventario de bienes inmuebles. Este no es el tipo de software que cambia el mundo. De hecho, es probable que ni siquiera ponga una sonrisa en la cara de alguien. Su único propósito es conseguir que los otros trabajadores sean más productivos .


Por poco interesante que pueda ser, nuestro trabajo es beneficioso *exclusivamente* para nuestro empleador, no para nuestra satisfacción personal. Eso es justamente lo que significa ser un profesional.


Estoy seguro de que muchos abogados motivados se enfrentarían rápidamente a un emocionante juicio con jurado, pero renunciarían a ello igualmente rápido si el mejor interés para su cliente fuera llegar a un acuerdo. Mientras que los arquitectos sueñan con oportunidades como Fallingwater, si el diseño requiere de un gran almacén con muelles de carga, entonces eso será lo que todos los planos reflejarán. Y si nuestro empleador necesita software para gestionar los pagos de facturas, entonces deberían conseguir exactamente eso, no un sistema “de plugins extensible basado en plantillas de interfaz de usuario analizadas en tiempo de ejecución” o cualquier otra cosa con la que nos engañamos a nosotros mismos en la creencia de que es necesario.



Repensando el Desarrollo de Software.

Por frustrante que pueda ser trabajar con un programador descuidado y sin inspiración, lo contrario -un programador inspirado aunque mal guíado- puede ser peor en varios órdenes de magnitud. Unos cuantos errores y un código doloroso de mantener palidecen ante los resultados desastrosos que un desarrollador incorrectamente motivado puede ofrecer.

Todo, desde la plataforma (“¡Vamos a probar Ruby!”) a la arquitectura ( “No se puede tener dos niveles”) a las técnicas utilizadas en el propio código (“necesitamos un marco orientado a aspectos”) puede ser -y a menudo está -influenciado más por el deseo de aprender la tecnología que el de servir a la necesidad real del negocio. Escoge la plataforma o la técnica equivocadas, y el proyecto está condenado inevitablemente .


Después de haber condenado más de un proyecto , como resultado de mi deseo de desafiarme a mí mismo , he llegado a saber que hay algunas reglas esenciales que se deben seguir en el desarrollo de sistemas de información de negocios.

1. Aprende el negocio . Es absurdo creer que no es necesario entender el negocio con el fin de desarrollar un software para él. Sin entender cuáles son sus necesidades reales, es imposible dar a los interesados ​​lo que en realidad necesitan. Eso sí: cuando dicen que quieren una “nueva base de datos para todos el día a día”, en realidad no significa que tengamos que crear una nueva base de datos cada día.

2. Sirve al negocio. Cada comerciante quiere utilizar las últimas herramientas y las más grandes y poderosas, pero rara vez son lo apropiado para el trabajo. Del mismo modo, casi nunca se da el caso de negocios que requiera actualizar de inmediato todas las plataformas / bibliotecas / idiomas. Ese código fuente de 10 años de edad “ASP clásico” no se ha desgastado, sólo es mucho menos divertido de mantener.

3. Aprende fuera del trabajo. La superación personal es un principio de todas las profesiones, pero el lugar para hacerlo que es “fuera del trabajo”, es decir, no durante el desarrollo sistemas de información. En vez de eso, aprende haciendo aplicaciones para tí mismo, tu equipo, o tal vez incluso participando en algunos proyectos de código abierto.

4. Escribe código de negocio mayormente. Si la inmensa mayoría de tu código escrito a mano no es de dominio específico y no se relaciona con el propósito de la aplicación, entonces estás utilizando las herramientas equivocadas. Si realmente crees que el sistema necesita un framework de logs personalizado, a continuación, exteriorízalo y consigue un desarrollo específico de la parte interesada .

5. El tedio es ineludible . Ningún mapeador O/R o generador de código van a resolver el hecho de que los registros, campos, validadores, etc tienen que estar definidos a mano por lo menos en dos lugares ( front y back-end ). Una interfaz de usuario generada a partir de la base de datos es tan mala como la base de datos que se genera a partir de la interfaz de usuario.

6. Encuentra la satisfacción en otro lugar. Si tu única satisfacción proviene de escribir código complejo, entonces nunca serás un buen desarrallodor de aplicaciones ni estarás satisfecho. Personalmente, estoy feliz de saber que ayudé a una mayor productividad para el usuario final y/o he creado nuevas oportunidades para la organización.

… Y , si todo lo demás falla …

7. consigue otro trabajo . Tal vez usted hayas alcanzado tu valor máximo. O tal vez estás cansado de este tipo de desarrollo en conjunto. De cualquier manera, hay un montón de oportunidades de programación por ahí que no involucran sistemas de información aburridos. Por supuesto, la competencia es mucho más feroz ahora que los programadores de bajo nivel se ocultan bajo el radar de las empresas de servicios de TI que controlan el mercado.

Al final, los mejores programadores no son los que crean el código más bonito y elegante ni el más sumamente innovador. Las verdaderas estrellas de rock pueden entregar el software antes de plazo, por debajo del presupuesto, y su código hace exactamente lo que necesita el negocio. Y ese es el tipo de profesional que todos debemos esforzarnos en ser.


Conclusión:
dejen de perder su vida y años de juventud sentados en una silla escribiendo texto que nadie valorara ni reconocerá como un trabajo de gran relevancia, solo te consideraran un peón mas del montón.
Aun estas a Tiempo!!
0
0
0
2
0No comments yet