style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">

Estimacion: Supuestos de Desempeño (Parte 5)

Una petición (que a menudo se convierte en exigencia) muy común que hacen los clientes, es una garantía de desempeño, cosas como:

  1. Quiero que todas las pantallas/paginas tengan un tiempo de respuesta máximo de 3 segundos.
  2. Quiero que todas las consultas tengan un tiempo de respuesta máximo de 3 segundos
  3. Quiero que el sistema corra en mi servidor (cuando bien nos va, nos dicen las características del servidor)

Que hacer en un caso así? Cuando yo acababa de salir de la carrera (hace ya más de una década) mi respuesta solía ser: "Necesito más datos", "Con la información que tengo no puedo garantizar ese desempeño", "No sé ni en que consiste el algoritmo para el proceso de cálculo de comisiones por ventas indirectas ¿cómo voy a garantizar que la pantalla donde veo el resultado de eso responda en 3 segundos???"

Casi sobra decir mi actitud era la actitud equivocada...

Mis preguntas me parecían lógicas, para mi dar una garantía de tiempo de respuesta de una página en 3 segundos, era como si me dijeran "vas a transportar una caja de un peso indeterminado, a través de una distancia desconocida, usando un mecanismo desconocido y tienes que garantizar que lo podrás hacer en 3 segundos".

Por supuesto que mi respuesta era: Si no conozco ni el peso, ni la distancia, ni el mecanismo no puedo garantizarte el tiempo....

Y la invariable respuesta de mis jefes: No me digas por qué no, dime "como si"... resultaba irritante para mis oídos.

Pero tenían razón, si te piden un tiempo garantizado de transporte, y no sabes ni el peso, ni la distancia, ni el mecanismo a utilizar, lo que se espera no es que digas "me faltan esos datos", lo que se espera es que digas bajo qué condiciones podrías hacerlo en el tiempo especificado (si ya luego el cliente no puede proporcionártelas, entonces no eres tú el que fallo)

Por supuesto esto no significa que no preguntes. Lo mejor siempre es preguntar. Pero paradójicamente, debes preguntar, pero sin que te preocupe mucho si te dan o no la respuesta. Habrá clientes a los que les interese que les construyas lo correcto. Esos clientes trataran de contestar tu pregunta dándote los parámetros que requieres. Habrá otros clientes a los que lo "correcto" no les importa, lo único que les importa es que se haga "correctamente" (que este bien hecho, aunque a ellos no les sirva). Este segundo tipo de clientes, a menudo se sentirán irritados con tus preguntas, inclusive llegaran a contestarte "tú eres el experto, yo no sé del tema, tu dime que necesitas para hacerlo  en el tiempo que yo lo requiero"... Habran casos en que tu cliente tenga suerte, y lo correcto y lo hecho correctamente coincidiran... pero recuerda siempre intenta hacer lo correcto, pero si tus recomendaciones se van a saco roto, no te irrites, y cambia de modo. No pienses que tu clientes es "tonto" o "malo" por exigirte el como si. Finalmente, el tiene razon, se supone que tu eres el experto: dile como si, y deja que el decida si tiene o no el presupuesto.

Así pues, todos los parámetros que faltan hay que suponerlos. Pongamos el caso más extremo, te piden el tiempo de respuesta de 3 segundos, y no te dan ninguna otra pista... y hay varios requerimientos en el sistema (como por ejemplo "visualizar comisiones por ventas indirectas "). No sabes cuantas ventas tienen, pero sabes que es un corporativo multinacional, y seguro que no son "poquitas"

¿Qué hacer? volvamos al ejemplo del paquete a transportar, si tuvieras que llevar un paquete:

Peso: Desconocido

Distancia: Desconocida

Mecanismo: Desconocido

Tiempo de transporte: 1 hora.

¿Qué harías?

Pues, podrías por ejemplo decir: En la canasta de mi bicicleta, cabe 1 litro de agua. Y en una hora, en mi bicicleta, recorro digamos 40 kilómetros, entonces:

Peso: 1 kilo

Dimensiones: máximo 15 cm cuadrados (el volumen que cabe en la canasta de la bicicleta)

Distancia: máximo 40 km

Mecanismo: Bicicleta

Tiempo de transporte: 1 hora.

Ahora, el gran error por lo que los supuestos como estos se consideran la madre de todos los males, es porque el que los supone, se los guarda hasta el día que el cliente quiere enviar un paquete, y resulta que hay que mandar media tonelada de ladrillos a 100km de distancia en máximo 2 horas... y no hay forma en el universo de hacer eso en la canasta de tu bicicleta...

Y entonces, viene el típico sermón: "no supongas!" "pregunta!"  (Lo cual se vuelve particularmente molesto, porque tú claramente recuerdas que le preguntaste al cliente y nunca te dio una respuesta clara)

¿El error estuvo en el supuesto? NO .

El error estuvo en que no hiciste PÚBLICO tu supuesto. No se lo comentaste verbalmente al cliente, se lo mandaste por email e intentaste que te firmara un documento aceptandolo. Ahora, bien, no falta el que piensa: "es que tendría que listar todas las posibilidades" ¿qué pasa si el paquete es de 100kg, que pasa si es de 10 metros cuadrados, que pasa si lo tengo que entregar en 15 minutos?. Ese es el enfoque incorrecto. El enfoque correcto es dar 1 solo ejemplo, pero bien claramente acotado.

Por supuesto, dirán algunos, habrá algo que se te pase: que pasa si el usuario te pide enviar 1 kilo de uranio? cumple con todo, pero te matara la radioactividad! no hay forma de pensar en todo.

Efectivamente, no la hay. Pero eso no es excusa para buscar acotar las cosas. Si te esfuerzas en acotar lo mejor posible tus supuestos, poco a poco estarán más completos, y después de algunos años, la experiencia te permitirá incluir suficientes factores para que la posibilidad de que te pidan transporta algo que viole tus supuestos haciéndote daño sea muy remota. Si al inicio de tu carrera como desarrollador, 9 de cada 10 supuestos te llevan a situaciones problematicas, y 10 años despues, solo 5 de cada 10 te llevan ahi, eso es un éxito

Volviendo al escenario que a nosotros como desarrolladores nos interesa, si te piden: “Quiero que todas las consultas tengan un tiempo de respuesta máximo de 3 segundos”

Establece supuestos:

  1. Numero máximo de registros por consulta.
  2. Peso máximo de datos de la consulta en Megabytes
  3. Velocidad de la red (Mbits/s)
  4. Características del hardware de todos los servidores y estaciones de trabajo clientes involucradas
  5. Tipo de operación (si es en SQL, número máximo de registros, existencia de índices, número máximo de registros en la tablas, número máximo de joins, versión de la pseudo-RDBMS, etc., etc., etc.)

En ingeniería civil, si un ingeniero quiere saber la resistencia de una barra de acero de 10 cm de grosor y 10 metros de largo, puede ir a un catálogo y conocerla….

¿No es tiempo ya de construir ese conocimiento para nosotros?

Por más que he buscado tablas con los datos de arriba, en donde alguien haya probado determinadas configuraciones “tipo” de hardware/software y algoritmos básicos”, algo así como:

Si tú haces un Join entre 2 tablas con tales y cuales columnas en Sql Server 2008R2, sobre un servidor i5, con 8Gbytes de RAM y un disco de tales y cuales características, con una red de… y sus combinaciones (finalmente, somos programadores, hacemos algoritmos, hagamos uno que genere X combinaciones).

¿Qué no será un benchmark que funcione de forma absoluta? Por supuesto que no lo será, pero ese no es el objetivo, el objetivo es poder ofrecer un supuesto razonable, y darle la confianza a tu cliente, que si las condiciones que estableciste se cumplen, puedes garantizar un resultado.

Ya si ya sobre la marcha ocurre otra cosa… pues no es tu culpa, no podias controlarlo, y el número de clientes que entenderán que no alcanzaste la meta porque ellos (o las circunstancias) violaron tus supuestos es (al menos en mi experiencia) mucho mayor que aquellos que te entenderán si desde el principio les dices “por qué no” en vez de “como si”

Recuerda, los supuestos no son malos. Si se le pides aun ingeniero civil que construya tu casa, no esperas contestarle sus dudas de resistencia de materiales, ese es no es tu trabajo. El trabajo del consultor (ya sea desarrollador de software, o ingeniero civil) es encontrar las condiciones bajo las cuales "si se puede", y en software, afortunada... o desafortunadamente casi todo se puede, si se cuenta con lo supuestos correctos

Comentarios

Opciones de visualización de comentarios

Seleccione la forma que prefiera para mostrar los comentarios y haga clic en «Guardar las opciones» para activar los cambios.
Imagen de ezamudio

benchmarks

Buen aporte. Sólo un comentario en cuanto a los benchmarks: si de plano necesitas tener esos datos, lo mejor es que hagas tu propio benchmark (no digo que escribas tu propio benchmark, pero sí que ejecutes algún software de medición en el ambiente donde vas a poner tu sistema).

El catálogo de ingeniería civil que mencionas, probablemente considere variaciones como la temperatura ambiental, humedad, etc. Pero el equivalente en software tendría demasiadas variables, porque los ambientes pueden variar demasiado, es como si tuvieras que hacer el catálogo tomando en cuenta un rango de temperatura de -200ºC a 3500ºC y una humedad que va desde 0 absoluto hasta "sumergido en H2O puro".

Siguiendo el ejemplo, el dato sólo sería confiable si el tiempo para el join entre 2 tablas incluye no sólo la versión de SQL Server, CPU, RAM, disco y red, sino además versión exacta de sistema operativo (obviamente, tal vez no lo mencionaste por ser tan obvio), configuración de filesystem (NTFS, FAT, etc) el tipo de RAID si es que hay, las condiciones del filesystem previas a la consulta (aunque se defina el tamaño de las 2 tablas, no es lo mismo en un filesystem altamente fragmentado y con poco espacio disponible que en un disco nuevecito que sólo tiene instalado el SQL Server), el número de procesos corriendo en ese momento (ajenos al SQL Server), y probablemente otras variables que ahorita se me escapan pero que no son tan fáciles de medir porque no es cosa de correr más procesos simultáneos o desfragmentar el disco o cosas así (simplemente hacer el benchmark para distintos tipos de RAID requiere mucho tiempo para estar jugando con eso porque hay que reinstalar todo desde cero cada vez, además de necesitar varios discos duros, etc). Y cuando el benchmark se vuelve tan específico, pues si tienes condiciones similares pero no idénticas luego no sirve de mucho, porque tener por ejemplo la mitad de RAM o de CPUs no significa que se va a tardar el doble, puede tardarse mucho más, o puede tardarse casi lo mismo.

Imagen de luxspes

benchmarks: ¿y si hacemos un repositorio?

El catálogo de ingeniería civil que mencionas, probablemente considere variaciones como la temperatura ambiental, humedad, etc. Pero el equivalente en software tendría demasiadas variables, porque los ambientes pueden variar demasiado

Estoy de acuerdo en que la variacion puede ser muy fuerte.

Siguiendo el ejemplo, el dato sólo sería confiable si el tiempo para el join entre 2 tablas incluye no sólo [...] (obviamente, tal vez no lo mencionaste por ser tan obvio) [...]. Y cuando el benchmark se vuelve tan específico, pues si tienes condiciones similares pero no idénticas luego no sirve de mucho, porque tener por ejemplo la mitad de RAM o de CPUs no significa que se va a tardar el doble, puede tardarse mucho más, o puede tardarse casi lo mismo.

Si, coincido completamente...

lo mejor es que hagas tu propio benchmark (no digo que escribas tu propio benchmark, pero sí que ejecutes algún software de medición en el ambiente donde vas a poner tu sistema).

Si, para sistemas de bases de datos, se puede partir de la base de los que hace el Transaction Processing Performance Council

Me pregunto si valdria la pena hacer algo como un repositorio estadistico... Algo como la data recopilada por PassMark pero mas agarrado a cosas "convencionales" y ejecutado dentro de software que tomara un snaphshot de las no-se-cuantas-mil-variables y que pudiera citarse cuando se tiene que hacer una propuesta de software y pudiera usarse para tener algo como el "HP Sharepoint Sizer" pero distribuido, abierto y de propósito mas general

Por supuesto los resultados estarian dados en rangos, con rendimientos promedios, y sin dejar nunca de lado la siempre olvidada desviación estandar.

Igual y es un sueño guajiro... pero en estos tiempos en que BigData, Machine Learning y Hadoop suenan tanto... igual y algo se puede hacer para modernizar este asunto... o igual y mas bien lo que falta es tomemos mas en cuenta los esfuerzos de organizaciones como el Transaction Processing Performance Council

Imagen de echan

mmmmmm algo como big

mmmmmm algo como big O?

http://bigocheatsheet.com/

como dice ezamudio hay muchas partes moviles en la medicion para cubrir todos los escenarios.. a lo mejor con big O junto con un buen numero de metricas y JMX se podria tener algo por el estilo

Imagen de 043h68

Gracias.

Hace un rato al fin tuve tiempo de leer toda la serie y la verdad es que esta genial, felicidades y gracias por estos aportes.

style="display:inline-block;width:728px;height:90px"
data-ad-client="ca-pub-5164839828746352"
data-ad-slot="7563230308">