Archivo

Archivos diarios: octubre 20, 2009

Pero necesario.

Si tienes un puesto de responsabilidad y la carga de trabajo es superior a lo que puedes soportar y/o rompe el equilibrio que te permite hacer tu trabajo correctamente, es necesario delegar.

Delegar supone dar responsabilidades y confiar en el trabajo de la persona en quien se delega (importante es que la empresa u organización en la que trabaja te de medios para poder delegar, es decir, en primer lugar recursos humanos suficientes y en segundo lugar recursos humanos que respondan), delegar no es llevar un control exhaustivo de la persona en quien se delega, porque de lo contrario no se consigue el objetivo que se persigue con la delegación de responsabilidades que es principalmente tener más tiempo para desempeñar otras, tan importantes o más que la que has delegado.

Creo en las aplicaciones beta en producción, la web 2.0 ha demostrado que se pueden tener productos accesibles al ciudadano de muy buena calidad en fase beta.

Eso sí, creo en las betas con calidad, en betas que funcionan aunque tengan alguna funcionalidad que todavía quede por implementar o incidencias que haya que corregir, pero que unas u otras no impidan un desempeño eficiente del usuario con la aplicación.

No hay que confundir las betas con las famosas versiones 0. Cuidado con las entregas de aplicaciones basadas en el concepto de versión 0 que consiste en: “ahí te entrego el producto, le faltan funcionalidades, no es robusto (estas dos cosas evidentemente no te la dicen), y…, este…. funciona”. Cuando la aplicación empieza a hacer aguas y te diriges a quien lo ha desarrollado para solicitar cambios y la corrección de las incidencias, ya te están poniendo el cazo, para la versión 1 o la 0.5.

Atacar directamente a un modelo de datos de otra aplicación incrementa el grado de acoplamiento entre sistemas y cuando este modelo se extiende a la mayoría de sistemas de información de una organización, se entiende que está implantado lo que se denomina modelo en spaghetti.

La teoría dice que hay que intentar reducir al mínimo el nivel de acoplamiento y que una de las posibilidades para reducirla se encuentra en el uso de APIs que utilizarán la tecnología que se elija en cada caso para suministrarle a una aplicación la información que necesita de otra.

Hasta ahí todo bien y estoy de acuerdo. La reducción del nivel de acoplamiento minimiza impactos en terceras aplicaciones que consumen o graban datos ya que si se conserva el API (los cambios son internos (principio de caja negra)) las aplicaciones que hacen uso del mismo no se enteran.

Me considero bastante ortodoxo (muy teórico) en el desempeño de mi labor profesional y en consecuencia eso se traduce en muchas de las decisiones que tomo, que como ya he dicho muchas veces en este blog, a veces son acertadas y otras equivocadas, ya que la teoría no vale para todos los casos o bien porque la teoría no se ha aplicado o interpretado correctamente. Lo que me enseñaron en la facultad era teoría (por muchas prácticas que tuvieran las asignaturas) y es lo que aplico, aunque afortunadamente la experiencia y tropezarse contra muchas piedras (alguna de ellas más de una vez) permite que donde han habido errores intente abordar el problema de otra manera.

En el asunto de las API podemos realizar la siguiente clasificación: las APIs que se utilizan porque no hay otra forma de obtener/grabar información en otro sistema (es decir, aquellas en las que no tenemos acceso al modelo de datos) y aquellas que se ponen por encima de un modelo de datos al que sí podemos acceder. En el primer caso, no hay más remedio que utilizar el API. En el segundo tenemos la posibilidad de elegir y si tenemos la posibilidad de elegir no hay que caer (yo he caído), en el error de aplicar la teoría a rajatabla y si el API no está bien construido o no es lo suficientemente eficiente, utilizar el API por narices. Si el API original está en nuestra manos mejorarlo y en un tiempo razonable sí que puede ser solución continuar con su uso, en caso contrario yo recomiendo una implementación alternativa o atacar directamente al modelo de datos, ya que lo primero es que las aplicaciones funcionen de forma eficiente y con usabilidad para el usuario, la ortodoxia viene después.

No es este un post en contra del uso de APIs, en absoluto, antes al contrario, ya he comentado que estoy totalmente de acuerdo con su uso (y que en ocasiones no hay otro medio para acceder/grabar la información) y en sus fundamentos teóricos, lo que quiero decir con este artículo esta expresado al final del párrafo anterior: lo primero, el usuario.

Seguir

Recibe cada nueva publicación en tu buzón de correo electrónico.

Únete a otros 3.198 seguidores