Buenos días, esta es prácticamente mi última entrada referente al tema de calidad, que a pedido de Drinky (Fary o Juan), ponemos a disposición de la gente un poco de teoría.-
Si bien es la última entrada referente al punto de calidad, en próximas entradas agregaré unos conceptos de abstracción, encapsulación, modularidad, un poquito de todo.
Luego de esto probablemente de por finalizado el Hilo de El Arte de Programar (no se guíen por las publicaciones etiquetadas en esto porque etiquete muchas cosas que no son precisamente teoría).-
Como se habrán dado cuenta aplicar calidad cuesta, y cuesta no por esfuerzo sino por el evidente motivo de que lleva su tiempo, y en esta industria, todo se cobra según el tiempo que lleva, el tiempo representa dinero y aquí es donde está el costo.
Tengo que suponer que a esta altura notaron que aplicar todos los criterios de calidad en primera instancia es bastante complejo ya que tienden a contradecirse en algunos puntos, por lo que si mejoramos en un punto, estamos empeorando en otro. Ya desde el vamos elegir correctamente los criterios a aplicar según la ocasión y el ambiente resulta de una tarea compleja, y más aún lograr mejorar todos los criterios de calidad sin empeorar dramáticamente algún otro, eh aquí la cuestión, de por que yo en entradas anteriores comentaba que la programación está dada por la resolución de problemas y que es una tarea de pensar, esta es una de las tantas razones por la que comenté eso.
Además del factor tiempo, y el factor de los inconvenientes que nos trae la implementación de varios criterios contradictorios, tenemos el factor costo, nosotros en muy rara ocasión podremos decirle al cliente esto le costará más, porque además de las funcionalidades que usted me pidió, yo le voy a agregar Reuso, si llegaron hasta acá y leyeron comprensiva mente las anteriores publicaciones, notarán que los factores de calidad internos (los que expliqué en publicaciones) en realidad el cliente no los aprecia, ni conoce su existencia, la utilidad de estos factores es para nosotros.
Claro ejemplo de Reusabilidad, el hecho de escribir un código y que si aparece un nuevo cliente y te pide aproximadamente lo mismo pero en un contexto diferente, puedas agarrar el mismo código y sin tocar una linea utilizarlo, es un hecho muy importante, ya que nosotros no le diremos al cliente "yo ya lo tenía hecho desde otra vez así que no se lo cobro", por supuesto que el debe pagar por el código que le estoy brindando, por más que yo ya lo tuviese si él lo pide a otro lo tendrá que pagar, el hecho es que yo ya no lo tengo que hacer de nuevo, no gasto ni 10 minutos de mi tiempo en ese código, y lo cobro por horas de trabajo que ya hice, notarán que esto se transforma en una ganancia.
Por otro lado si tomamos por ejemplo a Robustez, un factor sumamente importante, tanto como Reusabilidad, podemos notar que, si un cliente compró un software y no implicamos robustez, si algo falla el cliente aparecerá en nuestra puerta a decirnos "No me anda", y vamos a estar puteando 15 horas que NO VAMOS A COBRAR, para ver cual era el error en un código de hace meses que no tocamos mas y no nos acordamos nada. En este momento, la robustez nos salva, ya que si pasa algo inesperado muy probablemente nuestro código se comporte correctamente y no tengamos un cliente de hace 2 meses quejándose y golpeando nuestra puerta, con el costo que eso conlleva.
Si tomamos Corrección es bastante evidente cual es el problema que nos ocurriría, si nuestra corrección es incorrecta, y realmente el software no hace lo que debería, o lo que pidió el cliente, a los dos días lo vamos a tener golpeando la puerta de casa a ver si le devolvemos el dinero o le damos un programa que haga lo que él pide.
A todo esto no vamos a dejar de lado Extensibilidad, a los dos meses viene nuestro cliente original y quiere que además de todo lo que hace su programa también fría papas fritas, el problema de la falta de extensibilidad viene dada por, el costo que nos llevaría agregarle una nueva función sin que empiece a dar 15mil errores por todas partes del código, y tomarnos el trabajo de reparar mil cosas para agregarle algo nuevo. Si aplicamos un buen criterio de Extensibilidad, notaremos que agregar algo nuevo no nos traerá ningún inconveniente, cuando llegue ese momento solo implementaremos lo nuevo y todo saldrá andando, cobraremos lo que tenemos que cobrar, cliente feliz, programador feliz, no perdimos un centavo y seguimos andando bien.
En cambio si nos tira tantos errores, en código que ya no nos acordamos cuando lo hicimos, vamos a gastar más tiempo del que podemos cobrarle, porque imagínese el caso de que agregarle una pequeña función nos lleve el tiempo que tarda en construirse la mitad del sistema, querer cobrarle la mitad del tiempo que nos llevó será como querer cortarle la cabeza.
Para compatibilidad me da lastima explicarlo porque es muy sencillo, si el cliente quiere que su programa tenga un corrector ortografico, y nuestro sistema está bien armado en este criterio, nosotros seremos vivos y usaremos el corrector ortográfico de word, que sabemos que anda bien y no lo tenemos que programar.
Si no tenemos este criterio tendremos que programar todo el corrector ortográfico, que significa o menos ganancias, o más costo para el cliente, que a la larga muchas cosas que se podrían evitar con esto, suman y suman tanto al producto final que termina costando demasiado.
Eficiencia, evidentemente si nuestro programa se llama wordpress y le gusta comer los microprocesadores como si se tratara de golosinas, claramente cuando estemos en un ambiente que realmente trabajemos con personas que sepan lo que hacen, y que se trata de grandes cantidades de visitas, el consumo que les genera y podría ser tranquilamente evitado, también genera un costo, y cuando venga otro programador y le diga al cliente que puede evitar todo ese costo, nos quedaremos sin cliente.
Además que si se trata de una app de escritorio, aquellas que consumen y consumen recursos terminan no funcionando en la mitad de las computadoras, y eso dará una muy mala imagen de nosotros.
Hay otros factores, pero no vale la pena escribir sobre ellos, porque sus desventajas y ventajas son muy evidentes.
No aplicar estos criterios, dará como resultado, un monstruito, y como expliqué en ésta entrada, en la programación no hay balas de plata.
Quizás no todos puedan apreciar este tipo de cosas, ya que no todos viven de la programación, pero cuando la programación es un trabajo, y nos representa ingresos importantes, el hecho de no reparar en estas cosas, nos puede hacer fracasar, o dejarnos con muy poco tiempo libre, porque el resto o ganamos plata o arreglamos los errores que le surgen a los clientes enfadados. Si no se tiene en cuenta esto, programar cuando no es hobby, es una actividad muy compleja.
Un saludo y espero les haya gustado la entrada del día de hoy.-
Si bien es la última entrada referente al punto de calidad, en próximas entradas agregaré unos conceptos de abstracción, encapsulación, modularidad, un poquito de todo.
Luego de esto probablemente de por finalizado el Hilo de El Arte de Programar (no se guíen por las publicaciones etiquetadas en esto porque etiquete muchas cosas que no son precisamente teoría).-
En la entrada de hoy hablaremos sobre las dificultades de implementar calidad en software, de los factores que son puestos en el tablero para tomar decisiones de diseño si se quiere.
Como se habrán dado cuenta aplicar calidad cuesta, y cuesta no por esfuerzo sino por el evidente motivo de que lleva su tiempo, y en esta industria, todo se cobra según el tiempo que lleva, el tiempo representa dinero y aquí es donde está el costo.
Tengo que suponer que a esta altura notaron que aplicar todos los criterios de calidad en primera instancia es bastante complejo ya que tienden a contradecirse en algunos puntos, por lo que si mejoramos en un punto, estamos empeorando en otro. Ya desde el vamos elegir correctamente los criterios a aplicar según la ocasión y el ambiente resulta de una tarea compleja, y más aún lograr mejorar todos los criterios de calidad sin empeorar dramáticamente algún otro, eh aquí la cuestión, de por que yo en entradas anteriores comentaba que la programación está dada por la resolución de problemas y que es una tarea de pensar, esta es una de las tantas razones por la que comenté eso.
Además del factor tiempo, y el factor de los inconvenientes que nos trae la implementación de varios criterios contradictorios, tenemos el factor costo, nosotros en muy rara ocasión podremos decirle al cliente esto le costará más, porque además de las funcionalidades que usted me pidió, yo le voy a agregar Reuso, si llegaron hasta acá y leyeron comprensiva mente las anteriores publicaciones, notarán que los factores de calidad internos (los que expliqué en publicaciones) en realidad el cliente no los aprecia, ni conoce su existencia, la utilidad de estos factores es para nosotros.
Claro ejemplo de Reusabilidad, el hecho de escribir un código y que si aparece un nuevo cliente y te pide aproximadamente lo mismo pero en un contexto diferente, puedas agarrar el mismo código y sin tocar una linea utilizarlo, es un hecho muy importante, ya que nosotros no le diremos al cliente "yo ya lo tenía hecho desde otra vez así que no se lo cobro", por supuesto que el debe pagar por el código que le estoy brindando, por más que yo ya lo tuviese si él lo pide a otro lo tendrá que pagar, el hecho es que yo ya no lo tengo que hacer de nuevo, no gasto ni 10 minutos de mi tiempo en ese código, y lo cobro por horas de trabajo que ya hice, notarán que esto se transforma en una ganancia.
Por otro lado si tomamos por ejemplo a Robustez, un factor sumamente importante, tanto como Reusabilidad, podemos notar que, si un cliente compró un software y no implicamos robustez, si algo falla el cliente aparecerá en nuestra puerta a decirnos "No me anda", y vamos a estar puteando 15 horas que NO VAMOS A COBRAR, para ver cual era el error en un código de hace meses que no tocamos mas y no nos acordamos nada. En este momento, la robustez nos salva, ya que si pasa algo inesperado muy probablemente nuestro código se comporte correctamente y no tengamos un cliente de hace 2 meses quejándose y golpeando nuestra puerta, con el costo que eso conlleva.
Si tomamos Corrección es bastante evidente cual es el problema que nos ocurriría, si nuestra corrección es incorrecta, y realmente el software no hace lo que debería, o lo que pidió el cliente, a los dos días lo vamos a tener golpeando la puerta de casa a ver si le devolvemos el dinero o le damos un programa que haga lo que él pide.
A todo esto no vamos a dejar de lado Extensibilidad, a los dos meses viene nuestro cliente original y quiere que además de todo lo que hace su programa también fría papas fritas, el problema de la falta de extensibilidad viene dada por, el costo que nos llevaría agregarle una nueva función sin que empiece a dar 15mil errores por todas partes del código, y tomarnos el trabajo de reparar mil cosas para agregarle algo nuevo. Si aplicamos un buen criterio de Extensibilidad, notaremos que agregar algo nuevo no nos traerá ningún inconveniente, cuando llegue ese momento solo implementaremos lo nuevo y todo saldrá andando, cobraremos lo que tenemos que cobrar, cliente feliz, programador feliz, no perdimos un centavo y seguimos andando bien.
En cambio si nos tira tantos errores, en código que ya no nos acordamos cuando lo hicimos, vamos a gastar más tiempo del que podemos cobrarle, porque imagínese el caso de que agregarle una pequeña función nos lleve el tiempo que tarda en construirse la mitad del sistema, querer cobrarle la mitad del tiempo que nos llevó será como querer cortarle la cabeza.
Para compatibilidad me da lastima explicarlo porque es muy sencillo, si el cliente quiere que su programa tenga un corrector ortografico, y nuestro sistema está bien armado en este criterio, nosotros seremos vivos y usaremos el corrector ortográfico de word, que sabemos que anda bien y no lo tenemos que programar.
Si no tenemos este criterio tendremos que programar todo el corrector ortográfico, que significa o menos ganancias, o más costo para el cliente, que a la larga muchas cosas que se podrían evitar con esto, suman y suman tanto al producto final que termina costando demasiado.
Eficiencia, evidentemente si nuestro programa se llama wordpress y le gusta comer los microprocesadores como si se tratara de golosinas, claramente cuando estemos en un ambiente que realmente trabajemos con personas que sepan lo que hacen, y que se trata de grandes cantidades de visitas, el consumo que les genera y podría ser tranquilamente evitado, también genera un costo, y cuando venga otro programador y le diga al cliente que puede evitar todo ese costo, nos quedaremos sin cliente.
Además que si se trata de una app de escritorio, aquellas que consumen y consumen recursos terminan no funcionando en la mitad de las computadoras, y eso dará una muy mala imagen de nosotros.
Hay otros factores, pero no vale la pena escribir sobre ellos, porque sus desventajas y ventajas son muy evidentes.
No aplicar estos criterios, dará como resultado, un monstruito, y como expliqué en ésta entrada, en la programación no hay balas de plata.
Quizás no todos puedan apreciar este tipo de cosas, ya que no todos viven de la programación, pero cuando la programación es un trabajo, y nos representa ingresos importantes, el hecho de no reparar en estas cosas, nos puede hacer fracasar, o dejarnos con muy poco tiempo libre, porque el resto o ganamos plata o arreglamos los errores que le surgen a los clientes enfadados. Si no se tiene en cuenta esto, programar cuando no es hobby, es una actividad muy compleja.
Un saludo y espero les haya gustado la entrada del día de hoy.-
0 comentarios:
Publicar un comentario