viernes, 29 de enero de 2016

¿Te encuentras en un proyecto un huevo de grande?

En andalucía se oscila mucho las unidades de medida propias. Vienen a ser: el pelín, la mijilla, er peazo, la jartá, la pechá y el huevo.

Muchos proyectos de software se comportan de igual manera, de repente se transforman en un huevo de tediosas (tiempos y costes se disparan, incidencias de todo tipo, incluir una nueva y simple funcionalidad conllevan una jartá de esfuerzos, etc.), e igualmente, muchas veces, nos ofrecen, o buscamos, sugerentes vías de escape que, con apenas esfuerzo, nos solucionen el problema (bastaría pasar por algunos foros de software), tecnologías que de manera casi inmediata prometen acabar con la intensidad de un proyecto de software gigante. 

El tiempo ha dado lugar a la creación de un amplio cuerpo de conocimiento en ingeniería de software que nos ha enseñado la mejor manera de trabajar, afrontar o resolver problemas asociados a la naturaleza del software, como, por ejemplo, a no utilizar el “go to”, la importancia de la ocultación de la información, el diseño orientado a objetos, las arquitecturas en capas, cómo estimar proyectos, el valor de las mejoras, economia software, patrones, etc, etc, etc. Pero éstos, en más ocasiones de las que nos gustaría, se olvidan, o desconocen, y se buscan soluciones desde lo accidental (una determinada herramienta, entorno automático o CASE, cambiar a un lenguaje de programación, utilizar otro modelo de procesos, etc.). 

Como experiencia personal, la mayoría de los problemas del software parten de obviar los principios esenciales, y se incrementan al intentar solucionarlos exclusivamente desde la vía accidental. Como profesional deberíamos cuidar más el conocimiento esencial, la educación y formación en el mismo. El conocimiento accidental es necesario para poder trabajar, pero el esencial es necesario para además hacer un buen trabajo. El difundir y aprender el cómo trabajar correctamente con la parte esencial del software, esa jartá de conocimiento que existe y se ha ido creando a lo largo de la cronología del software, es quizás uno de los principales retos de nuestra profesión y muchos deberían aprender a apreciarlo en su justa medida. Muchos han sido los  partífices en estableces esas bases.

1 comentario:

  1. Totalmento de acuerdo desde el punto de vista tecnico-manager. Desde el punto de vista manager-direccion-recursos humanos, a los encargados de liderar y llevar a buen termino el proyecto, y que les importase "un huevo" la calidad del producto a entregar, asi como la "pecha" de currar y la "harta" de presion que ha inyectado al equipo de trabajo, opino que la direccion no deberia tardar ni "pelin" en decirle a recursos humanos que no tardase ni una "mijita" en echarlo a la p... calle, para dejar paso a algun "peaso" de profesional cualificado que sepa lo que esta haciendo, y no sea un mero relaciones publicas empresarial. Dicho todo sin acritud, of course.

    ResponderEliminar