Es Momento de Aplicar Reingenieria

"Las aplicaciones requieren constante mantenimiento y actualización. A veces la mejor actualización es su reescritura completa"

Como todos bien sabemos, todas las cosas especialmente los sistemas informáticos tienden a perder utilidad con el tiempo, ya sea debido a que no se adapta a los nuevos avances en hardware, no es compatible con las nuevas plataformas de ejecución o no logra satisfacer las nuevas necesidades del usuario.

De la misma manera como los activos fijos tienen su depreciación y fecha de expiración, cada programa de computadora tiene(o debería tener) definido su período de vida, de manera que los usuarios sepan cuándo sea el momento de reemplazarlos por otros más modernos. Lamentablemente no existe una unidad de medida infalible para saber cuándo un sistema informático ha expirado.

Cuando esto ocurre, es hora de aplicar reingeniería y empezar a rediseñar los sistemas existentes, manteniendo su funcionalidad actual pero utilizando herramientas de desarrollo mas ágiles, técnicas y disciplinas mas ordenadas y frameworks que permiten la extensibilidad del mismo, además de aprovechar para agregar nuevas características que pueda necesitar el usuario.

Si algo ya no sirve, vuélvelo a hacer desde cero.

Si es un programa hecho en Visual Fox Pro 6 que comparte archivos de tablas en una carpeta de red, aunque aún le sea útil al usuario, tú como programador sabes que será un completo dolor de cabeza tratar de consumir web services o transportar datos por Message Queue por lo que en lugar de seguir manteniendo un sistema pasado de moda desarrollado con código obsoleto, es mejor reescribirlo desde cero usando tecnologías que te ahorrarán mucho trabajo en el desarrollo y con capacidad de extenderlo según aparezcan nuevos estándares.

Desarrolla pensando en el futuro.

Como desarrollador puedo estar seguro que los usuarios no siempre saben lo que quieren que haga un sistema y cambian de opinión a medida que el sistema va siendo desarrollado. Por tal motivo, debes tener esto en cuenta a la hora de desarrollar tu sistema y diseñarlo de tal forma que pueda ser adaptable a posibles cambios, que tu sistema no "suponga" ni "imagine" que X o Y proceso se hace de tal manera, que todas las decisiones de negocio sean configurables! Ademas, permite que el programador que retomará tu sistema sea capaz de entenderlo y agregar nuevas funcionalidades que sean requeridas por los usuarios. Como una vez alguien escribió en Stack Overflow Programming Quotes:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. (Siempre programa como si el que mantendrá tu código será un violento psicópata quien sabe donde vives)

-- Rick Osborne

Demuestrale al usuario que algo ha cambiado, y porqué este cambio es para mejora

Como escribí antes, el usuario está conforme y acostumbrado al viejo sistema del año 2000 que le resuelve a medias sus necesidades actuales y posiblemente el cambio que apliques no sea visible en la interfaz sino que solamente en las tecnologías de desarrollo. Aun así, hay que reflejar ese cambio también en la interfaz de usuario aplicando alguna nueva plantilla CSS(en el caso de una aplicación web), agregando nuevos servicios que quizá no eran necesarios pero que reflejen el cambio o agregando una sección de "Nueva versión, nuevas características" a manera de hacerle notar al usuario que algo ha cambiado y poder explicarle cuál es la nueva manera como ahora se realizan los procesos X y Y.

"Los developers de Gmail siempre han tenido la bondad de notificarnos cuando hay nuevas características disponibles"

Recuerden que en última instancia, nuestro trabajo como desarrolladores es satisfacer los deseos más oscuros y enajenados las necesidades de información de los usuarios de negocio en la empresa, por lo que tampoco es bueno pensar en reescribir todos los sistemas de la empresa solo por estar "in" en tecnologías de desarrollo de software.

agil calidad codigo computadoras desarrollo empresa fox gmail programacion productividad

Es Momento de Aplicar Reingenieria

"Las aplicaciones requieren constante mantenimiento y actualización. A veces la mejor actualización es su reescritura completa"

Como todos bien sabemos, todas las cosas especialmente los sistemas informáticos tienden a perder utilidad con el tiempo, ya sea debido a que no se adapta a los nuevos avances en hardware, no es compatible con las nuevas plataformas de ejecución o no logra satisfacer las nuevas necesidades del usuario.

De la misma manera como los activos fijos tienen su depreciación y fecha de expiración, cada programa de computadora tiene(o debería tener) definido su período de vida, de manera que los usuarios sepan cuándo sea el momento de reemplazarlos por otros más modernos. Lamentablemente no existe una unidad de medida infalible para saber cuándo un sistema informático ha expirado.

Cuando esto ocurre, es hora de aplicar reingeniería y empezar a rediseñar los sistemas existentes, manteniendo su funcionalidad actual pero utilizando herramientas de desarrollo mas ágiles, técnicas y disciplinas mas ordenadas y frameworks que permiten la extensibilidad del mismo, además de aprovechar para agregar nuevas características que pueda necesitar el usuario.

Si algo ya no sirve, vuélvelo a hacer desde cero.

Si es un programa hecho en Visual Fox Pro 6 que comparte archivos de tablas en una carpeta de red, aunque aún le sea útil al usuario, tú como programador sabes que será un completo dolor de cabeza tratar de consumir web services o transportar datos por Message Queue por lo que en lugar de seguir manteniendo un sistema pasado de moda desarrollado con código obsoleto, es mejor reescribirlo desde cero usando tecnologías que te ahorrarán mucho trabajo en el desarrollo y con capacidad de extenderlo según aparezcan nuevos estándares.

Desarrolla pensando en el futuro.

Como desarrollador puedo estar seguro que los usuarios no siempre saben lo que quieren que haga un sistema y cambian de opinión a medida que el sistema va siendo desarrollado. Por tal motivo, debes tener esto en cuenta a la hora de desarrollar tu sistema y diseñarlo de tal forma que pueda ser adaptable a posibles cambios, que tu sistema no "suponga" ni "imagine" que X o Y proceso se hace de tal manera, que todas las decisiones de negocio sean configurables! Ademas, permite que el programador que retomará tu sistema sea capaz de entenderlo y agregar nuevas funcionalidades que sean requeridas por los usuarios. Como una vez alguien escribió en Stack Overflow Programming Quotes:

Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live. (Siempre programa como si el que mantendrá tu código será un violento psicópata quien sabe donde vives)

-- Rick Osborne

Demuestrale al usuario que algo ha cambiado, y porqué este cambio es para mejora

Como escribí antes, el usuario está conforme y acostumbrado al viejo sistema del año 2000 que le resuelve a medias sus necesidades actuales y posiblemente el cambio que apliques no sea visible en la interfaz sino que solamente en las tecnologías de desarrollo. Aun así, hay que reflejar ese cambio también en la interfaz de usuario aplicando alguna nueva plantilla CSS(en el caso de una aplicación web), agregando nuevos servicios que quizá no eran necesarios pero que reflejen el cambio o agregando una sección de "Nueva versión, nuevas características" a manera de hacerle notar al usuario que algo ha cambiado y poder explicarle cuál es la nueva manera como ahora se realizan los procesos X y Y.

"Los developers de Gmail siempre han tenido la bondad de notificarnos cuando hay nuevas características disponibles"

Recuerden que en última instancia, nuestro trabajo como desarrolladores es satisfacer los deseos más oscuros y enajenados las necesidades de información de los usuarios de negocio en la empresa, por lo que tampoco es bueno pensar en reescribir todos los sistemas de la empresa solo por estar "in" en tecnologías de desarrollo de software.

agil calidad codigo computadoras desarrollo empresa fox gmail programacion productividad

Internet a traves del Mail: Es posible?

Existen empresas en el país que como bien lo dice Rodrigo en este post, no valoran lo suficiente a su equipo de IT por lo que no son tan flexibles a la hora de considerar las necesidades que este equipo tiene para lograr el éxito en el desarrollo de los proyectos de software.

Un claro ejemplo de esto es cuando te restringen el acceso a Internet con el supuesto de volverte más productivo evitando que pierdas el tiempo procrastinando en lugar de desarrollar, ya que los jefes no conocen el valor único que tiene el Internet y cuantos servicios online existen que te permiten ser más productivo especialmente si formas parte de un equipo de trabajo.

"Para algunos jefes, esto es el Internet"

Para lograr dicho cometido, he encontrado los siguientes sitios que te pueden ser de mucha utilidad:

• Twittermail (http://twittermail.com/)
  

Este es un sitio desde el cual puedes registrarte con tu usuario y clave de twitter y al momento te asignan una dirección de correo electrónico especial, a la cual puedes escribir y el título o el contenido de dicho correo (depende de como lo hayas configurado) saldrá publicado en tu cuenta de twitter. También puedes enviar comandos especiales en el título del correo, como por ejemplo friends con el cual, el robot te enviará un correo electrónico conteniendo los 20 últimos twitts escritos por tus amigos.

Dicha cuenta, además, te enviará a tu bandeja un mail con los repplies que recibas por parte de tus followers. Entre otras funciones esta la capacidad de publicar fotografías adjuntas en twitpic y programar twitts a futuro.

• Postear en el Blog (blogger)

Las plataformas de blogging también te ofrecen la alternativa de escribir posts y enviarlos a una cuenta de correo especifica para que este sea publicado. Desde blogger puedes hacerlo en la siguiente pagina, en tus settings:

"Interfaz de los settings de tu cuenta de blogger, donde puedes configurar una cuenta de correo para publicar posts en tu blog (Clic para agrandar)"

• Webinmail (http://www.webinmail.com)

Este servicio te permite enviar un correo electrónico a una cuenta de correo predeterminada, incluyendo en el título del mensaje la URL de la página que deseas visitar y ellos te envían un correo de respuesta mostrando dicha página web en el contenido del correo. Ejemplo:

"Ejemplo de mensaje de correo electrónico enviado a webinmail, pidiendo recibir la pagina del Sr Byte (Clic para ver en tamaño completo)

"Mensaje de correo recibido en respuesta por la consulta enviada anteriormente. (Clic para ver en tamaño completo)"

Quizá la forma de negación parezca un tanto arcaica y no te permita descargar archivos o recibir transmisiones de audio/vídeo vía streaming para ver vídeos de youtube o entrar a sitios que te piden tu usuario y clave pero por lo menos te puede sacar de apuros si no tienes nada mas que tu cuenta de correo electrónico y necesitas googlear o buscar ayuda en foros.

cloud empresa gmail google internet tecnicas tecnologia twitter util web+2.0 youtube email

Internet a traves del Mail: Es posible?

Existen empresas en el país que como bien lo dice Rodrigo en este post, no valoran lo suficiente a su equipo de IT por lo que no son tan flexibles a la hora de considerar las necesidades que este equipo tiene para lograr el éxito en el desarrollo de los proyectos de software.

Un claro ejemplo de esto es cuando te restringen el acceso a Internet con el supuesto de volverte más productivo evitando que pierdas el tiempo procrastinando en lugar de desarrollar, ya que los jefes no conocen el valor único que tiene el Internet y cuantos servicios online existen que te permiten ser más productivo especialmente si formas parte de un equipo de trabajo.

"Para algunos jefes, esto es el Internet"

Para lograr dicho cometido, he encontrado los siguientes sitios que te pueden ser de mucha utilidad:

• Twittermail (http://twittermail.com/)
  

Este es un sitio desde el cual puedes registrarte con tu usuario y clave de twitter y al momento te asignan una dirección de correo electrónico especial, a la cual puedes escribir y el título o el contenido de dicho correo (depende de como lo hayas configurado) saldrá publicado en tu cuenta de twitter. También puedes enviar comandos especiales en el título del correo, como por ejemplo friends con el cual, el robot te enviará un correo electrónico conteniendo los 20 últimos twitts escritos por tus amigos.

Dicha cuenta, además, te enviará a tu bandeja un mail con los repplies que recibas por parte de tus followers. Entre otras funciones esta la capacidad de publicar fotografías adjuntas en twitpic y programar twitts a futuro.

• Postear en el Blog (blogger)

Las plataformas de blogging también te ofrecen la alternativa de escribir posts y enviarlos a una cuenta de correo especifica para que este sea publicado. Desde blogger puedes hacerlo en la siguiente pagina, en tus settings:

"Interfaz de los settings de tu cuenta de blogger, donde puedes configurar una cuenta de correo para publicar posts en tu blog (Clic para agrandar)"

• Webinmail (http://www.webinmail.com)

Este servicio te permite enviar un correo electrónico a una cuenta de correo predeterminada, incluyendo en el título del mensaje la URL de la página que deseas visitar y ellos te envían un correo de respuesta mostrando dicha página web en el contenido del correo. Ejemplo:

"Ejemplo de mensaje de correo electrónico enviado a webinmail, pidiendo recibir la pagina del Sr Byte (Clic para ver en tamaño completo)

"Mensaje de correo recibido en respuesta por la consulta enviada anteriormente. (Clic para ver en tamaño completo)"

Quizá la forma de negación parezca un tanto arcaica y no te permita descargar archivos o recibir transmisiones de audio/vídeo vía streaming para ver vídeos de youtube o entrar a sitios que te piden tu usuario y clave pero por lo menos te puede sacar de apuros si no tienes nada mas que tu cuenta de correo electrónico y necesitas googlear o buscar ayuda en foros.

cloud empresa gmail google internet tecnicas tecnologia twitter util web+2.0 youtube email

Mas Alla del Codigo: Escalabilidad

"Tu sistema debe ser capaz de crecer junto con tu negocio, para soportar la demanda del mercado"

El año pasado, Fafamonge me preguntó una vez cuánta influencia creía yo que podría tener el Internet y los blogs en las elecciones que estamos celebrando, a lo cual yo respondí que relativamente poca o casi nula, considerando que somos un país demasiado conservador con poca cultura tecnológica, en comparación con otros hermanos latinoamericanos como Chile o Brasil pero ahora que se celebraron las elecciones de diputados y alcaldes, quizá mi perspectiva podría variar un poco.

Me he dado cuenta que los encargados de IT del tribunal supremo electoral compartían mi idea y nunca esperaron la saturación en el tráfico que ha tenido el sitio web de dicho organismo durante las elecciones y al parecer, lo mismo podría suceder con el sistema utilizado para el conteo de votos y transmisión de resultados. Lo mismo nos ocurría en la universidad cuando realizabamos exámenes en línea o al momento de realizar inscripciones en línea. Los servidores donde la aplicación web estaba alojada colapsaba por el exceso de tráfico.

"El ejemplo más claro de falta de escalabilidad: Twitter en sus inicios"

Para evitar estos inconvenientes, es necesario tomar en cuenta la cantidad de usuarios que harán uso de nuestras aplicaciones al momento de desarrollarlas y publicarlas, además de considerar si tu sistema será capaz de crecer para adaptarse a estas nuevas necesidades de rendimiento.

Lo más común es agregar mas recursos al servidor como mas RAM o un CPU más rapido. Otros optan por el Cloud Computing, de manera que varias computadoras actuen como una sola y la suma de sus recursos sea suficiente para mejorar el rendimiento de la aplicación lo cual en parte si ayuda. Todo lo anterior es tarea de arquitectos de hardware/software y sysadmins pero nosotros como desarrolladores también tenemos que realizar nuestro aporte pensando en aplicaciones que consuman solamente los recursos necesarios y capaces de crecer y adaptarse a las nuevas necesidades cuando estas aparezcan, de manera que no sea necesario reescribir por completo el código fuente.

Como desarrollador, recomiendo hacer código lo mas genérico posible, no hagas código para solucionar problemas específicos en el momento que estos surgen, haz código que resuelva las necesidades de información actuales y las que podrían aparecer en un futuro y si no fuera capaz de resolverlas, que por lo menos sea lo suficientemente flexible para que se pueda adaptar sin perder mucho tiempo en este proceso. Por supuesto, esto no lo puedes decidir si ya estas en la fase de desarrollo, esto debes hablarlo con los involucrados en el proyecto una vez que este ha nacido, para que se reserve el suficiente tiempo para esta tarea.

Dentro de pocos meses se llevarán a cabo también las elecciones presidenciales. Crees que volveremos a ver otra failwhale en el sitio del TSE y similares?

cloud codigo computadoras desarrollo el+salvador elecciones empresa politica programacion twitter

Mas Alla del Codigo: Escalabilidad

"Tu sistema debe ser capaz de crecer junto con tu negocio, para soportar la demanda del mercado"

El año pasado, Fafamonge me preguntó una vez cuánta influencia creía yo que podría tener el Internet y los blogs en las elecciones que estamos celebrando, a lo cual yo respondí que relativamente poca o casi nula, considerando que somos un país demasiado conservador con poca cultura tecnológica, en comparación con otros hermanos latinoamericanos como Chile o Brasil pero ahora que se celebraron las elecciones de diputados y alcaldes, quizá mi perspectiva podría variar un poco.

Me he dado cuenta que los encargados de IT del tribunal supremo electoral compartían mi idea y nunca esperaron la saturación en el tráfico que ha tenido el sitio web de dicho organismo durante las elecciones y al parecer, lo mismo podría suceder con el sistema utilizado para el conteo de votos y transmisión de resultados. Lo mismo nos ocurría en la universidad cuando realizabamos exámenes en línea o al momento de realizar inscripciones en línea. Los servidores donde la aplicación web estaba alojada colapsaba por el exceso de tráfico.

"El ejemplo más claro de falta de escalabilidad: Twitter en sus inicios"

Para evitar estos inconvenientes, es necesario tomar en cuenta la cantidad de usuarios que harán uso de nuestras aplicaciones al momento de desarrollarlas y publicarlas, además de considerar si tu sistema será capaz de crecer para adaptarse a estas nuevas necesidades de rendimiento.

Lo más común es agregar mas recursos al servidor como mas RAM o un CPU más rapido. Otros optan por el Cloud Computing, de manera que varias computadoras actuen como una sola y la suma de sus recursos sea suficiente para mejorar el rendimiento de la aplicación lo cual en parte si ayuda. Todo lo anterior es tarea de arquitectos de hardware/software y sysadmins pero nosotros como desarrolladores también tenemos que realizar nuestro aporte pensando en aplicaciones que consuman solamente los recursos necesarios y capaces de crecer y adaptarse a las nuevas necesidades cuando estas aparezcan, de manera que no sea necesario reescribir por completo el código fuente.

Como desarrollador, recomiendo hacer código lo mas genérico posible, no hagas código para solucionar problemas específicos en el momento que estos surgen, haz código que resuelva las necesidades de información actuales y las que podrían aparecer en un futuro y si no fuera capaz de resolverlas, que por lo menos sea lo suficientemente flexible para que se pueda adaptar sin perder mucho tiempo en este proceso. Por supuesto, esto no lo puedes decidir si ya estas en la fase de desarrollo, esto debes hablarlo con los involucrados en el proyecto una vez que este ha nacido, para que se reserve el suficiente tiempo para esta tarea.

Dentro de pocos meses se llevarán a cabo también las elecciones presidenciales. Crees que volveremos a ver otra failwhale en el sitio del TSE y similares?

cloud codigo computadoras desarrollo el+salvador elecciones empresa politica programacion twitter

Mas Alla del Codigo

"Escribir el código es sólo una parte del proceso de desarrollo de software"

Últimamente en mi trabajo me he dado cuenta que en las grandes ligas, el código es nada mas una de todas las cosas por las que hay que preocuparse a la hora de desarrollar un sistema. No basta con ser un programador disciplinado, dejando comentarios en el código, haciendo pruebas de unidad, subversionando y diseñando una interfaz agradable al usuario para que nuestra aplicación sea usable, hay que pensar en otros factores que podrían afectar nuestra aplicación a la hora que esta sea usada en el mundo real.

Algunas de estas cosas no las descubres en la universidad, cuando ejecutas tus aplicaciones en un ambiente ideal, donde no introduces más de cien registros a tu base de datos y sólo tienes a 5 usuarios al mismo tiempo accediendo a tu aplicación y lo hacen desde una LAN.

Tampoco piensas en que tan fácil será extender tu aplicación cuando la empresa crezca y surjan nuevas necesidades de información o si tu aplicación puede migrarse a otras plataformas o comunicarse con otros sistemas.

Estos conceptos los descubres y aplicas una vez que ya estás involucrado en un proyecto que requiere aplicarlos por lo que dedicaré algunos posts para que tomemos en cuenta que otras fases se llevan a cabo una vez que has escrito el código o qué otras características debes tomar en cuenta mientras lo escribes.

codigo desarrollo diseño empresa productividad programacion tecnicas tecnologia

Mas Alla del Codigo

"Escribir el código es sólo una parte del proceso de desarrollo de software"

Últimamente en mi trabajo me he dado cuenta que en las grandes ligas, el código es nada mas una de todas las cosas por las que hay que preocuparse a la hora de desarrollar un sistema. No basta con ser un programador disciplinado, dejando comentarios en el código, haciendo pruebas de unidad, subversionando y diseñando una interfaz agradable al usuario para que nuestra aplicación sea usable, hay que pensar en otros factores que podrían afectar nuestra aplicación a la hora que esta sea usada en el mundo real.

Algunas de estas cosas no las descubres en la universidad, cuando ejecutas tus aplicaciones en un ambiente ideal, donde no introduces más de cien registros a tu base de datos y sólo tienes a 5 usuarios al mismo tiempo accediendo a tu aplicación y lo hacen desde una LAN.

Tampoco piensas en que tan fácil será extender tu aplicación cuando la empresa crezca y surjan nuevas necesidades de información o si tu aplicación puede migrarse a otras plataformas o comunicarse con otros sistemas.

Estos conceptos los descubres y aplicas una vez que ya estás involucrado en un proyecto que requiere aplicarlos por lo que dedicaré algunos posts para que tomemos en cuenta que otras fases se llevan a cabo una vez que has escrito el código o qué otras características debes tomar en cuenta mientras lo escribes.

codigo desarrollo diseño empresa productividad programacion tecnicas tecnologia

En una empresa: el codigo es el enemigo.

Voy a escribir un par de artículos a la semana, hace poco conseguí trabajo y me esta consumiendo, pero las experiencias y habilidades son invaluables.

El código en exceso es malo. Requiere mantenimiento periódico. Posee errores ... que deben ser encontrados, depurados y mitigados. Añadir funcionalidad extra, implica que el código antiguo se tiene que adaptar.


Mientras hay mas código escrito:

• Existen mas lugares en donde se esconden los infames bugs (que se combaten depurando o escribiendo más código)
  
• El proceso de compilación tarda mas tiempo
  
• Los Checkouts del repositorio de control de versiones también se alargan
• Un empleado nuevo tardara más tiempo en comprender el sistema
• Es mas complicado refactorizar código
• Y también es mas difícil encontrar documentación precisa de: que hace qué, cuándo, dónde y por qué.
  

"Este libro debería leerse en la Universidad..."

Más código, significa menos flexibilidad y funcionalidad; esto para muchos es una paradoja, pero la mayoría de veces, una solución simple, rápida y elegante, es mejor que una "mega super función general que hace de todo".

"Este es más común..."

El código es escrito por ingenieros de sistemas, técnicos programadores o consultores; digamos simplemente que son desarrolladores. Producir más código, requiere mas desarrolladores. Varios desarrolladores deben comunicarse. Un desarrollador tiene un costo de "canal de comunicación" de n^2, como pueden ver, las comunicaciones incrementan exponencialmente con cada desarrollador en el proyecto ( 1^2=2, 2^2=4, 3^2=9, etc...).
Añadamos un poco de papeleo (burocracia) a los canales de comunicación:

• Control de actividades de desarrollo, por metas y diarias.
• Documentos que constan la finalización de las actividades programadas.

... si hago esto por cada desarrollador... termino con un enorme costo organización, en función del tiempo gastado en cada desarrollador, o en función de un nuevo puesto de trabajo para que alguien realice esta tarea.

¿No se debería hacer todo lo posible para incrementar la productividad del individuo en términos del buen código que este escribe? La idea es simple: Escribir menos código para hacer algo (y si se puede, que sea buen código). Si tiene que escribir menos código, se contratan menos personas, y se reducen los costos de comunicación.

Después de todo, una buena empresa debe ser eficiente y eficaz, ¿no?. Si algo ya existe, úselo. Si hay mejores tecnologías, procure utilizarlas. Y si sus desarrolladores le dicen que hay que utilizar una nueva tecnología, procure prestar atención a lo que dicen, y si es factible hágalo.

"Buen equipo, buena silla, buen escritorio... son necesarios para producir buen código."

La comodidad de un desarrollador de software no puede ser discutida. Estos merecen buenas sillas, estar cómodos en sus cubículos o escritorios, café cerca y como máximo, ocho horas de trabajo diarias. El trabajo de un desarrollador de software, no solo es uno de los mas estresantes, sino también es uno de los mejor remunerados. Y si no trata bien a sus desarrolladores, estos producen código enmarañado, descuidado e irresponsable, hackeado para que funcione (ley del llegue)... malo en pocas palabras. Codificar mal, siempre es producir mas código del que se necesita.


Repitan conmigo:

"desarrolladores infelices, producen mal código, que aumenta mis costos".

En la empresa en la que estoy trabajando, la mayoría de desarrolladores piensan que los "usuarios" son los enemigos. Para mi, el código es el enemigo, y para la empresa también.

Una cosa más, para los desarrolladores que leen este articulo... sigan como consejo la sabiduría innegable de xkcd:

programar opinion codigo empresa programador desarrollo

En una empresa: el codigo es el enemigo.

Voy a escribir un par de artículos a la semana, hace poco conseguí trabajo y me esta consumiendo, pero las experiencias y habilidades son invaluables.

El código en exceso es malo. Requiere mantenimiento periódico. Posee errores ... que deben ser encontrados, depurados y mitigados. Añadir funcionalidad extra, implica que el código antiguo se tiene que adaptar.


Mientras hay mas código escrito:

• Existen mas lugares en donde se esconden los infames bugs (que se combaten depurando o escribiendo más código)
  
• El proceso de compilación tarda mas tiempo
  
• Los Checkouts del repositorio de control de versiones también se alargan
• Un empleado nuevo tardara más tiempo en comprender el sistema
• Es mas complicado refactorizar código
• Y también es mas difícil encontrar documentación precisa de: que hace qué, cuándo, dónde y por qué.
  

"Este libro debería leerse en la Universidad..."

Más código, significa menos flexibilidad y funcionalidad; esto para muchos es una paradoja, pero la mayoría de veces, una solución simple, rápida y elegante, es mejor que una "mega super función general que hace de todo".

"Este es más común..."

El código es escrito por ingenieros de sistemas, técnicos programadores o consultores; digamos simplemente que son desarrolladores. Producir más código, requiere mas desarrolladores. Varios desarrolladores deben comunicarse. Un desarrollador tiene un costo de "canal de comunicación" de n^2, como pueden ver, las comunicaciones incrementan exponencialmente con cada desarrollador en el proyecto ( 1^2=2, 2^2=4, 3^2=9, etc...).
Añadamos un poco de papeleo (burocracia) a los canales de comunicación:

• Control de actividades de desarrollo, por metas y diarias.
• Documentos que constan la finalización de las actividades programadas.

... si hago esto por cada desarrollador... termino con un enorme costo organización, en función del tiempo gastado en cada desarrollador, o en función de un nuevo puesto de trabajo para que alguien realice esta tarea.

¿No se debería hacer todo lo posible para incrementar la productividad del individuo en términos del buen código que este escribe? La idea es simple: Escribir menos código para hacer algo (y si se puede, que sea buen código). Si tiene que escribir menos código, se contratan menos personas, y se reducen los costos de comunicación.

Después de todo, una buena empresa debe ser eficiente y eficaz, ¿no?. Si algo ya existe, úselo. Si hay mejores tecnologías, procure utilizarlas. Y si sus desarrolladores le dicen que hay que utilizar una nueva tecnología, procure prestar atención a lo que dicen, y si es factible hágalo.

"Buen equipo, buena silla, buen escritorio... son necesarios para producir buen código."

La comodidad de un desarrollador de software no puede ser discutida. Estos merecen buenas sillas, estar cómodos en sus cubículos o escritorios, café cerca y como máximo, ocho horas de trabajo diarias. El trabajo de un desarrollador de software, no solo es uno de los mas estresantes, sino también es uno de los mejor remunerados. Y si no trata bien a sus desarrolladores, estos producen código enmarañado, descuidado e irresponsable, hackeado para que funcione (ley del llegue)... malo en pocas palabras. Codificar mal, siempre es producir mas código del que se necesita.


Repitan conmigo:

"desarrolladores infelices, producen mal código, que aumenta mis costos".

En la empresa en la que estoy trabajando, la mayoría de desarrolladores piensan que los "usuarios" son los enemigos. Para mi, el código es el enemigo, y para la empresa también.

Una cosa más, para los desarrolladores que leen este articulo... sigan como consejo la sabiduría innegable de xkcd:

programar opinion codigo empresa programador desarrollo