Antipatrón. Vaca del dinero

Hay organizaciones que más pronto o más tarde terminan encontrando un producto o una serie de productos o un cliente o una serie de clientes que le permiten tener un éxito en el mercado, superior al de otras compañías del sector.

Lo peor que le puede pasar a las empresas que han encontrado su vaca del dinero es pensar que ya han alcanzado la meta y que de allí no les va a mover nadie.

Gran error. La competencia apretará más fuerte y será cada vez más numerosa, el mercado y las tendencias cambian, hoy puedes ser el rey, mañana el príncipe destronado y pasado puede que ya no te conoce nadie.

Hasta las empresas más consolidadas, con más fidelización de sus clientes, saben que o evolucionan o pierden.

Desarrollo de software. Antipatrón. Codificación brutal

Se puede considerar un caso particular del antipatrón “productividad a toda costa“.

Se llega al mismo cuando se decide afrontar la programación de un proyecto, independientemente de la metodología utilizada, sin que se tengan definidos requisitos y/o la arquitectura.

Se tira hacia adelante con una venda en los ojos.

Lo más normal es que actuando de esta forma, se tenga que desandar varias veces el camino avanzado y se tiene todas las de perder ante el cliente, ya que siempre podrá argumentar que se han tomado decisiones que no estaban consensuadas con él.

El producto final no solo requiere más esfuerzo (al fin y al cabo se han tenido que tirar y levantar funcionalidades), sino que también verá afectada su calidad, ya que probablemente el proveedor, quiera de alguna forma atenuar las posibles pérdidas y también por el hecho de que las vuelta a atrás no terminan ser del todo limpias.

Desarrollo de software. Antipatrón. Caminar por un campo de minas

Delegar funcionalidad en componentes externos, hacer uso de librerías que nos sirvan de apoyo para implementar las funcionalidades, reutilizar código, etc… todo lo que sea ahorrar esfuerzo en el desarrollo y simplificar la ejecución del desarrollo debe ser bienvenido.

Pero no todo vale. Y es que a veces el remedio puede ser peor que la enfermedad.

Si el componente, librería o código no están bien probados y presentan deficiencias, tendremos un problema, que será todavía mayor si no controlamos o tenemos acceso al código fuente para realizar las correcciones oportunas o si dependemos de un tercero, tener la garantía de que el mismo va ir liberando versiones con asiduidad en las que se van corrigiendo esas incidencias.

El problema será mayor cuanto más tarde nos demos cuenta de la situación y cuanto más dependencia tenga el sistema de información que se está desarrollando de ese componente.

Es importante no tener que reinventar nada, pero más importante todavía resulta que el componente o artefacto que vayamos a utilizar esté probado, muy probado. Si no es así, no aconsejo que se utilice, salvo que se use para desarrollar una determinada funcionalidad residual en el sistema (y aún en esta circunstancia habría que pensárselo), porque en la construcción y lo que es peor, una vez el producto en producción, la sensación será como caminar por un campo de minas.