¿Comodidad, miedo o demasiados cambios constantes?

Traigo hoy al blog una reflexión que no por ser demasiado comentada por muchos es menos interesante. Hablaré de este tema desde el punto de vista subjetivo e imparcial de mi propia experiencia como programador por cuenta propia y ajena. Durante mi trayectoria profesional me he encontrado en todo tipo de situaciones que me llevan a pararme a hacer esta reflexión: ¿los desarrolladores de software nos acomodamos, tenemos miedo a avanzar o hay demasiados cambios constantes en nuestros desarrollos para quedarnos estancados?

Veréis, cuando yo empecé en esto de la informática, allá por 1984, aprendí RPGII, Cobol y Basic.  En aquella empresa, dedicada al proceso de datos de cámara bancaria y otras empresas, además de desarrollos de software para grandes empresas, se programaba casi todo en RPGII (o en Cobol para los bancos), pero al poco aparecieron los primeros PC’s que se programaban en BASICA y sin pensarlo dos veces se abordó el tema de aprender programarlo y desarrollar aplicaciones para esos aparatos.

Al poco me cambié de empresa y allí me pedían conocimientos de dBASEIII y Clipper, yo no tenía ni la más remota idea de que era eso, pero no me encabezoné (como hacen muchos) en obcecarme con el BASICA para programar y por mi cuenta aprendí todo lo que pude en 10 días para poder optar al puesto de trabajo que para mí significaba una importante mejora profesional.

No voy a contaros mi vida profesional desde este artículo, sería larga y aburrida, lo que si voy a contaros son los motivos que me han llevado a escribirlo.

Durante todo estos años he conocido empresarios que me contrataron, según ellos, para renovar el software y hacer avanzar la empresa; nada más lejos de la realidad, al poco tiempo de estar trabajando me encontraba parcheando programas arcaicos que costaban la misma vida mantenerlos. Como es normal, plantee en varias ocasiones a la dirección de la empresa la necesidad de renovar el software para adaptarlo a las tendencias, encontrándome con un terrible muro de miedo al cambio, de comodidad con la herramienta, de respuestas del tipo “no podemos parar el mantenimiento de las aplicaciones y ponernos a desarrollar con otra herramienta más moderna”. Lo entiendo, pero tampoco se hacía caso a la posibilidad de realizar desarrollos paralelos, dedicándole un rato cada día, para avanzar. Cuando se abordaban nuevos desarrollos, no se planteaba realizarlos con otra herramienta de programación que no fuese la que llevaban usando 10 o más años.

Yo mismo, durante una época, fui de los que se pensaban que con lo que hacía era más que suficiente y que dedicar tiempo y esfuerzo a estudiar, aprender o implementar algo nuevo era una mala inversión. No me acuerdo cual fue  el motivo, como se encendió la mecha del cambio, pero en poco tiempo ya estaba buscando libros, artículos, información, cursos y todo tipo de cosas que pudiese aprender y aplicar a mis quehaceres diarios, abriéndose un mundo de posibilidades.

He visto empresas de software que poco a poco han ido perdiendo posición en el mercado por haberse casado con una herramienta de desarrollo única, que no daba más de sí que lo que tenía. Directivos de empresa que en vez de dedicar esfuerzos a formar a sus empleados para mejorar su producto de cara al cliente, se han cerrado en banda con la única intención de reducir costes y así hacerse la ilusión de ingresar más.

Hoy en día veo empresas (dirigidas por personas que conozco, aprecio y con las que tengo amistad) que han convertido su software en el monstruo de las mil cabezas, imposible de mantener, imposible de entender. Veo directivos a los que se les ofrece la oportunidad de mejorar con poco desembolso económico que se aferran al desarrollo que tienen hecho y con el que llevan un montón de años sin darse cuenta que cada día que pasa es otro día perdido y otra oportunidad de mejorar que se evapora.

Y todos esto es por que se han acomodado dentro de un hueco que aún les da para vivir; por que tienen miedo a hacer cambios, a aprender algo nuevo, a soportar algún tipo de curva de aprendizaje que les incomode; por que no paran de hacer cambios a la aplicación que les da de comer, diariamente hacen muchos cambios, cambios que les llevan un tiempo cada vez mayor por que la aplicación es incomprensible y está tan enredada que seguirla es un caos; o bien, sencillamente, una mezcla de los tres casos.

Anuncios

14 comentarios

  1. Ciertamente todos nos encontramos antes o después alimentando monstruos de mil cabezas, aunque también a veces es responsabilidad nuestra como programadores y no solo de los propietarios y directivos de las empresas en cuestión. En mi caso tengo dos empresas con dos software de este tipo que llevo mucho tiempo pensando en abordar el cambio pero solo de pensar en tamaña tarea me da una pereza horrible, pero también cada vez que tengo que hacer un cambio me llevan los demonios y vuelvo a plantearme el cambio. Es como tener un angelito sobre un hombro y un demonio sobre el otro, supongo que os suena la sensación no?

    Salu2

    • Hola Bingen,

      Gracias por el comentario.

      Ciertamente es así, y algún día hay que tomar la decisión, contar con el apoyo de los clientes (hay que comunicarles lo que vas a hacer) y ponerse manos a la obra. Debemos superar el temor de que los clientes se molesten o que decidan por irse con otro (quizá es lo que más nos preocupa), hay que conseguir que el cliente se involucre en el proceso de cambio y que acepte que durante un periodo de tiempo no solicite cambios o que los cambios que solicite se incluirán en la nueva versión mejorada.

      Un abrazo.

  2. Estimado Alfonso, gracias por compartir tus ideas.

    En líneas generales compartimos historias laborales similares, aunque en distintos paises.

    Al trabajar en forma independiente debemos asumir que la decisión de cambiar es nuestra. El cambio es un preceso contínuo. Siempre fue así y seguirá siéndolo ( aunque nuestro deseo sería, quizá, que fuese menos violento y veloz, que nos deje respirar un poco )

    Se me ocurren dos lineas de acción:

    – Desde lo técnico dedicar siempre un tiempo para aprender los nuevos conceptos y utilizar herramientas de base solida y probada. Los cambios procedural -> POO , MVC, etc. fueron (son) difíciles. Hay que leer y aprender, o sea: capacitarse. No queda otra.

    – Desde lo ‘comercial’ compartir, discutir y hasta decidir ‘junto’ a nuestros clientes los cambios de uso y tecnología que vamos a implementar en los sistemas. Y digo ‘junto’ a los clientes porque la decisión de cambio es nuestra pero ellos son los destinatarios. Me está funcionando con los clientes. Algunos se entusiasman con cada paso que damos, lo esperan y lo ‘festejan’. Eso ayuda.

    El tema da para mucho, solo comparti estas ideas.
    Estamos en contacto,
    Claudio

  3. Jose que tema, es nudo de los que programamos en forma independiente, el punto me parece son las necesidades del cliente yo hasta hace 8 años programaba todo en Clipper y me negaba a ver que los pedidos de los clientes con mi herramienta no podia solucionarlos hasta que comence con Xailer. Mientra pueda cubrir las necesidades de clientes es dificil que cambie, el dia que no pueda voy a tener que esforzarme, y el otro tema es que con los años (muchos) uno se vuelve rapido para solucionar los pedidos (modificaciones de programas) de cliente por eso cuesta cambiar porque al comenzar el cambio uno nota que pierde competividad. Y por ultimo como cuesta trabajar con una herramiento no muy difundida a veces uno se siente el tonto que no programa en visual wxyz y no deberia ser asi, muchas veces me han dicho porque no cambio a visual wxyz asi podria tener muchos programadores que trabajen para mi, pero por el punto de la velocidad no lo hice me siento muy rapido programando en xBase.

    Saludos Atte
    Christian Assenza

    • Hola Christian,

      Gracias por el comentario.

      Desde luego que hay muchos programadores de “visual lo que sea”, ya se ocupó el fabricante de hacer que los centros de formación, desde academias privadas hasta universidades, se ocupasen de implantarlos como asignatura curricular. También, antes, cuando todo se hacía en DOS, se implantó Clipper 5 como asignatura curricular.

      Aunque con el artículo abordo todos los aspectos que hace que los programadores (independientes o a sueldo) nos aferremos con fuerza a nuestras costumbres, también me refiero a los que habiendo dado ya uno paso importante y decido cambiar la herramienta, no han cambiado la forma de trabajar y se han quedado construyendo otros monstruo de las mil cabezas con una nueva herramienta y se niegan a adquirir nuevos conocimientos y a aplicar nuevas técnicas a sus desarrollos.

      Un saludo.

  4. José Alfonso, por los lenguajes que comentas cuando empezaste a trabajar, tenemos los mismos años, jajajaja. Decirte que cuando me pasé a Clipper se abrió un mundo nuevo para mi. Despues pasé por el Visual FoxPro que es le lenguaje que manejo ahora. Con un Excelente ERP conectado con MySQL. Pero…… Como migro ese monstruo de mil cabezas?. A Xailer por ejemplo?. Hacer lo mismo con otro lenguaje xbase de escritorio?. Desde luego es una disyntiva a la que hace mucho tiempo que le doy vueltas, un saludo amigo.

    • Hola Ontario.xb,

      Gracias por el comentario.

      Lo primero que tienes que hacer antes de ponerte a migrar tu monstruo de mil cabezas a Xailer es volver a estudiarlo e intentar aplicar nuevas técnicas de programación que a la larga te faciliten la tarea de mantenerlo. No se si me sigues habitualmente, pero llevo tiempo escribiendo artículos explicando esas técnicas que son novedosas para xBase.

      Saludos.

  5. Coincido con vos Jose es cierto, yo tenia un mounstro de mil cabezas en Clipper y ahora tengo uno de 999 cabezas en Xailer y si si veo el codigo que escribi en Xailer es 99% parecido al de clipper. Tambien sucede que cuando vi el mounstro de mil cabezas me dije un dia debo comenzar y vi todo lo que me funciono en Clipper y lo pase a Xailer. La verdad es que mientras funcione no me preocupo pero a veces un pequeño fracaso me haria repensar todo mientras funcione no veo el motivo, es como decia Einstein las crisis son las que traen la creatividad.
    Saludos

  6. José Alfonso,

    El nicho de trabajo que nos va quedando es el de los programas a medida. ¿ por qué ? Porque para standard, los clientes ya tienen el sage o el sap o etc..
    Luego, vas al cliente “a medida” y le dices que su programa, rehacerlo, le va a costar nnnn dólares, y él, casi indignado, te dice que no sé qué programa que hace un montón de cosas le cuesta nnnn- nnn dólares menos que el tuyo.
    Entonces te dices, “necesito vender mucho para vender barato”, pero claro ! eso necesita dos cosas: un programa que esté a la última en tecnología y a la misma vez, un programa que sea completito. ¿ de cuántas horas hablamos ? ¿ de cuántos costes de elaboración hablamos ? Y sobre todo, en estos tiempos de crisis, los grandes siguen evolucionando, pero ¿ y los pequeños ? ¿ tienen nuestros clientes ganas de invertir dinero en software ?

    En todo caso se hace imprescindible la actualización de conocimientos para seguir en la brecha.

    El amigo.

    PD. Ya me pasaré a por el premio 😉

    • Hola amigo.

      Bueno, tú verás. Tarde o temprano tu cliente de aplicación a medida requerirá que le hagas más cosas y serás tu el que se lamente de que tu programa monstruo de las mil cabezas se haya vuelto prácticamente imposible de mantener. Eso si no te pide alguna funcionalidad que no puedas darle por que no está soportada en el entorno con el que trabajas.

      Migrar un software a medida hacia nuevos paradigmas de programación no tiene por que ser a costa del cliente, sobre todo si la mejora nos va a facilitar el trabajo. Y tampoco hay que medirlo todo en términos económicos, está claro que no trabajamos por amor al arte, pero a veces hay que amar lo que uno hace y eso, amigo, no se puede cuantificar.

      Saludos.

  7. Jose, coincido totalmente con tu razonamiento y veo que no soy el unico que tuvo y tiene que atravesar por el mismo camino tortuoso del cambio no solo de “herramienta” sino tambien de paradigmas, de conceptos y hasta de formas de pensar. Vos sabes porque te lo eh comentado personalmente ( skype) que a eso debes sumarle la soledad de nuestra labor cuando debes contar con ayuda humana presencial formada y ademas con ganas de aprender, tarea Dura si las hay. Pero bueno no queda otra que tomar LA DESICION de cambiar y hacer lo mas corta que se pueda la curva de aprendizaje. En mi caso luego de 21 años de Clipper 5 y de haber pasado por intentos fallidos con Delphi, Visual Wxxx ( como dice el amigo ) , .NET y otros mas que no merecen ni ser mencionados estoy convencido de estar en el camino correcto via Xailer , TU Blog con POO, MVC y Complements.lib. El paso siguiente es convencer a los clientes de los beneficios de la migracion. Por lo pronto les hice saber que el soporte para versiones en DOS tiene fecha de Vencimiento y que deberan actualizarse ( un poco de Facto ) en aras de tener mayor productividad ambos, y bajar los costes de mantenimiento. Hay mucho por hacer, y eso es lo bueno cuando uno ama lo que hace y ademas nos da para vivir.

    Saludos

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: