La ética profesional del programador ante el desastre de un sistema.

Pensemos en que estamos en el comienzo de el desarrollo de un ERP  en una empresa relativamente inexperta en tecnología  que   tiene ya un ERP con mas de 10 años de funcionamiento escrito en COBOL, la meta del departamento en el que estamos es remplazarlo de forma paulatina e indolora. Se comienza el desarrollo queriendo hacer todo bien, se levantan los requerimientos se hacen diagramas de procesos  y mockups de la interfaz pantalla por pantalla especificando   el mas mínimo detalle.

Se empieza la fase de programación y las cosas no son tan bellas. los requerimientos que dieron los gerentes se contradicen con las practicas que hace el usuario final, las interfaces son extremadamente difíciles de  hacer por que se pensaron para satisfacer la retina del “cliente” y no desde  lo mas optimo técnicamente, ademas se saltaron conceptos básicos de usabilidad. Los tiempos se vienen encima  y obligan a los programadores a ensuciar su código  para terminar la funcionalidad; “-el código no importa mientras funcione, con eso no nos despedirán!-“  cada vez el sistema es mas inmantenible, cada modificación a un modulo afecta a 5 módulos mas… los quiebra  y entonces tenemos que empezar a escribir artilugios que repiten fragmentos de código iguales a otros decenas de veces.  Los programadores empiezan a abandonar. ¿quien no lo aria? el barco se hunde  y ellos solo ganan una décima parte de lo que gana el gerente de sistemas el cual les echa la culpa de todo.  Nuevos programadores entran sin saber nada de las tripas del sistema  y  la dirección se niega a que tengan un curso de capacitación de 15 días.”- ¿estudiaron en la escuela no?  ¡ya deberían saber!-”

La historia termina años después sin un solo programador del equipo original, los nuevos programadores exigen que se reescriba de cero, dirección accede  y todo comienza de nuevo.

 

Imagine que es médico y un paciente le exige que no se lave las manos antes de la operación por que se pierde demasiado tiempo. En este caso el paciente es el jefe/cliente pero el medico debe negarse a lo que pida. ¿Por qué? Porque el médico sabe más que el paciente sobre los riesgos de infecciones. No sería profesional (incluso sería ilegal) que el médico cediera a las exigencias del paciente.

Tampoco sería profesional que los programadores cedieran a la voluntad de los jefes que no entienden los riesgos de un posible desastre

– Codigo limpio Robert C. Martin –

 

Hay varios problemas desde el inicio, como ¿a quien se le ocurre basar un ERP en un análisis TOP-DOWN?  ¿por que la necesidad de definir interfaces y sus flujos en la etapa mas temprana del desarrollo cuando la experiencia nos dicta que esto es de las partes mas cambiantes? y peor aun ¿por que decidir que  cometer un error a corto plazo para cumplir los tiempos de entrega es una jugada razonable? Todo buen desarrollador  de software debe saber que  un error, mas otro error, mas otro error, colocados apropósito para cumplir metas conducen a un desarrollo cada vez mas lento. Las preguntas adecuadas a estos problemas podrían ser: ¿fueron nuestros tiempos iniciales demasiado optimistas?, ¿Las funcionalidades que requería el sistema en un inicio han cambiado demasiado?

En conclusión la mejor forma de evitar un desastre es no provocarlo  nosotros mismos.

 

Martin Quinta

Crecí con una computadora desde el kinder. Empece a programar a los 14 y hoy, mas de una década después… realmente odio estar frente a una computadora. Pero programar es en lo que soy bueno, por lo tanto me desahogo en este blog mientras bebo cerveza artesanal y pienso en un mundo bonito donde Java no existe.

Facebook Twitter LinkedIn  

Entradas relacionadas:

3 comentarios en: “La ética profesional del programador ante el desastre de un sistema.

  1. Todo se debe a las prácticas antiguas que se utilizan en el desarrollo de software. Adoptar el manifiesto ágil debería de ser para el programador como el juramente hipocrático para los médicos.

    “Individuos e interacciones sobre procesos y herramientas.
    Software funcionando sobre documentación extensiva.
    Colaboración con el cliente sobre negociación contractual.
    Respuesta ante el cambio sobre seguir un plan.”

    http://www.agilemanifesto.org/iso/es/

    Por cierto, genial tu blog.

    Dark_Kase

Leave a Reply

Your email address will not be published. Required fields are marked *