Ouracademy

Cuando no seguir un consejo general

Basado en LimitationsOfGeneralAdvice de Martin Fowler

Al diseñar una base de datos (BD) o al diseñar casos de prueba o incluso cuando desarrollamos una estrategía organizacional siempre nos guiamos de principios, patrones o consejos generales.

Por ejemplo, si seguimos los 12 factores para construir un Software como Servicio (SaaS) nuestra aplicación funcionará muy bien si la desplegamos en Heroku.

Los speakers y escritores de software, por lo general dan muchos consejos, consejos generales sobre muchas areas de software: testing, diseño, delivery, analisis, etc. No solo consejos especificos sino tambien filosoficos, como dice Martin Fowler.

A pesar de la cantidad de consejos generales que existe, hay limitaciones significativas de su valor.

  • Siempre hay una gran brecha entre lo que dice un consejo general y como se aplica a una circunstancia particular (por eso es que los consultores están tentados a decir muchas veces "depende"). Para aquel que da el consejo, es muy pero muy dificil que conozca cada uno de los circunstancias particulares y reestricciones que suceden en un proyecto, eso indica que aquellos que tomamos los consejos debemos tomar el consejo "a la mitad" y decidir como aplicarlos a nuestras circunstancias. Cuando escuchamos esos consejos que dicen "siempre haz esto.." debemos ser cautelosos y pensar en los factores lo que conduce a 1 u otra respuesta (como decir "depende", la cual es una buena respuesta solo si es que sabemos de que depende). Sin embargo, cuando damos un consejo o tomamos uno,es muy bueno describir que motivos hacen que tomemos una alternativa (por ejemplo, si queremos aplicar la refactorizacion de una BD como "mover una columna de una tabla a otra tabla", debemos saber los motivos de hacerlo o no y sus alternativas).
  • Todo aquel que da un consejo, siempre está limitado a su experiencia. Y siempre está es limitada (Nadie sabe todo!), más aún cuando nuestra industria cambia tan rápido. Por eso es muy bueno cuando damos un consejo...apoyarnos no solo de nuestra experiencia sino tambien de otros, de tal manera que el consejo sea más objetivo y se refine con la ayuda de varias personas.
  • Y que más de decir de seguir esos consejos "generales" escoden motivos financieros (oye es mejor que escojas tal herramienta XYZ!).

A si que con todas estas limitaciones. Uno se podría preguntar ¿vale la pena esos consejos generales? Si la hay, en el sentido que son un punto de partida para tomar una decisión. Nos dan las cosas, los problemas, que debemos considerar en nuestro caso particular, reduciendo las probabilidades que nos la olvidemos esos casos. Es buena idea aprender muchos consejos generales, por que nos harán saber que posibles problemas podriamos tener.

Es esos problemas subyacentes la parte importante de todo este articulo, saber los motivos que conducen a tomar una decisión es más importante que simplemente seguir un consejo que te diga directamente que decisión tomar. ¿Prefieres que te digan que hacer o saber el por qué de hacerlo?

Cambios y revisiones:

30/01/2020: improve readability

27/01/2020: fix some typos

27/01/2020: new post when not follow a general advice

Si te fue útil este artículo, por favor compártelo. Apreciamos los comentarios y el aliento.
Compartelo por:

Quiza te pueda interesar...

Unit Test: que no es?

Quieres saber si tu prueba es un unit test, bueno aca un test de lo que no es un unit test: • Si se conecta con una base de datos • Si se…

Detestable: testing

Tu sistema no es testeable?, bueno aquí un término para ese problema

TestInvariant: TDD y DbC

Una idea que mezcla Test Driven Development (TDD) y Design by Contract (DbC).