Antipatrones de Diseño


Ya comenté sobre el  Lenguaje de patrón y de su aplicación  en diseño web.
ahora comentaremos brevemente sobre los antipatrones.


Un antipatrón de diseño es un patrón de diseño que invariablemente conduce a una mala solución para un problema.

Los antipatrones se consideran una parte importante de una buena práctica de programación o de diseño. Es decir, un buen programador, o diseñador, procurará evitar los antipatrones siempre que sea posible, lo que requiere su reconocimiento e identificación.

Se plantean varias "categorías" de antipatrones en el desarrollo de software, pero los mismos son extrapolables al ámbito del diseño web, directa o indirectamente, por encontrarnos muchas veces los diseñadores envueltos en procesos que nos trascienden e involucran otras partes.

Estas categorías los clasifican en grupos: antipatrones de gestión, de programación, de diseño orientado a  objetos, etc.
Mencionaré algunos con los que he tenido experiencias en mis ámbitos laborales, y que justifican ciertos comentarios que he venido realizando en el blog sobre mi perspectiva del asunto.


  • Productividad a toda costa:
    Se considera una antipatrón de gestión, y tiene lugar cuando se busca la productividad a costa de la calidad del software (o el diseño) y de la calidad de vida de sus empleados.
    Esta productividad, hace referencia a 
    la relación entre la cantidad de productos obtenida por un sistema productivo y los recursos utilizados para obtener dicha producción.
  • Negociador de jaula de acero (cage match negotiator):También se considera un antipatrón de gestión, y ocurre cuando un coordinador, gestor o responsable aplica una filosofía de "éxito a cualquier precio".
    Este éxito puede ser la satisfacción del cliente (aún si sus requerimientos son contraproducentes), el cumplimiento de los plazos, la minimización de costos, etc.
  • Gran bola de lodo (big ball of mud):Se considera un aintipatrón de diseño, e implica construir un sistema sin estructura definida
    (para luego ir improvisando a medida que vaya surgiendo).
  • Punto de vista ambiguo (ambiguous viewpoint):También es cosiderado un antipatrón de diseño, y se relaciona con el anterior.
    Éste consiste en presentar un modelo sin concretar ciertos aspectos, postergando así decisiones conflictivas.
  • Lava seca (lava flow): Código muerto e información de diseño olvidada permanecen congelados en un diseño cambiante.
  • Bala de plata (silver bullet):
    Se considera un error de metodología (si no lo son todos al final de cuentas).
    Consiste en asumir que nuestra solución técnica favorita puede resolver un problema mucho mayor, o cualquiera.
  • Desarrollo conducido por quien prueba (tester driven development):Permitir que un proyecto software avance a base de extraer sus nuevos requisitos de los informes de errores.
  • Programación de copiar y pegar (copy and paste programming):
    Programar copiando y modificando código existente en lugar de crear soluciones genéricas.
  • Diseño en comité (design by committee):Contar con muchas opiniones sobre un diseño, pero carecer de falta de una visión unificada.
  • Escalada de compromiso (escalation of commitment):No ser capaz de revocar una decisión a la vista de que no ha sido acertada.
  • Funcionalitis creciente (creeping featuritis):
    Añadir nuevas funcionalidades al sistema en detrimento de su calidad.
  • Gestión porque lo digo yo (management by perkele):
     
    Aplicar una gestión autoritaria con tolerancia nula ante las disensiones.
  • Gallina de los huevos de oro (cash cow):Pecar de autocomplacencia frente a nuevos productos por disponer de un producto legacy* .
Existen numerosos antipatrones descritos, esos son sólo unos pocos, pero son he que visto claramente más a menudo, y que me han conducido a grande dolores de cabeza en el trato con clientes y empleadores.
Estos son algunos tales, como la falta de tiempo para ciertas consideraciones porque el cumplimiento de plazos y horas pautadas, tener que manejarse con sistemas o métodos que se sabe no son eficientes pero son económicos, o muy familiares (o sencillamente la única forma en que se sabe resolver cierto aspecto puntual).
Crear funcionalidades a demanda del cliente y no del producto o los usuarios, (esto sucede con clientes que no tienen claro el producto que quieren obenter, pero que piensan que "más es más" y la actitud de quien tiene el mando es solamente complacer a quien paga, aunque a la larga se esté perjudicando).
Testeos  efectuados exclusivamente (y en el mejor de los casos) por testers,  que ponen a prueba la funcionalidad pero no usabilidad ni experiencia de usuario.
Arrancar el proyecto por el desarrollo (programación) para luego tener que hacer que el diseño encaje dentro de lo prestablecido,  y  que hacen que el usuario se adapte al sistema y no viceversa.
Reciclar un sistema previamente desarrollado para un cliente anterior, para uno nuevo con requerimientos en apareciencia parecidos, haciendo el mínimo de ajustes necesarios.
En fin, como ya he expresado otras veces, y reconozco que me ha costado trabajos, hasta que no se tenga la conciencia real de que para ganar hay que invertir,  es muy poco probable que  "productos de calidad" deje de ser meramente una muletilla de la carta de presentación de las empresas y los profesionales.
Este invertir no necesariamente significa más dinero, más tiempo, o reducir las ganancias.
A veces simplemente implica una utilización eficiente de los recursos, capitales y humanos.
Y para ganar está todo, los productos que generemos reflejan y representan nuestro trabajo, como empresas o como profesionales.
Un producto de calidad refleja una empresa o profesional con la misma cualidad, nos posiciona en el mercado,  fideliza clientes y capta nuevos.
Hay algo muy básico, aunque obviamente nos brinde satisfacciones ya que es aquello a lo que nos dedicamos, no diseñamos ni desarrollamos para nosotros, sino para aquellos que deseamos que consuman nuestros productos, que no son ni siquiera los clientes, sino los usuarios finales.
Si perdemos esto de vista, cualquier producto que generemos que resulte relativamente o muy exitoso, será un golpe de suerte, y no algo que podamos replicar y sostener en adelante.

Toda herramienta que pueda ayudarnos a mejorar los productos que creamos, debe ser bienvenida e interiorizada. La Usabilidad, la experiencia de usuario, los patrones, etc.  forman parte de la batería de conocimientos que debemos tener y utilizar en nuestro trabajo diario, no son snobismos de diseñadores new age.
Son aspectos intrísecos de los productos que generamos y que pretendemos vender, de una u otra forma y de las pautas que determina nuestro mercado, los usuarios.


*legacy: un sistema informático (equipos informáticos o aplicaciones) que ha quedado anticuado pero continúa siendo utilizado por el usuario (típicamente una organización o empresa) y no se quiere o no se puede reemplazar o actualizar de forma sencilla.

ver Introducción al lenguaje de patrón
ver Aplicación del lenguaje de patrón en diseño web

Magical Mystery Tour

No hay comentarios.:

Publicar un comentario