Costos de calidad del software [Re: Ley de Presupuesto SW Libre y ACTI]

[Horst H. von Brand]

Franco Catrin L. <fcatrin en tuxpan.com> wrote:
> El sáb, 29-11-2008 a las 23:25 -0300, Horst H. von Brand escribió:
> > Hay quienes difieren. Si se requiere documentacion del codigo, el codigo no
> > se entiende y es malo. Si el programa requiere extensa documentacion extra,
> > es demasiado complejo de usar y no sirve.

> Hay varios niveles de documentación, no solo el código. Por ejemplo
> diseños de alto nivel o API's.  En general, cosas que no se pueden
> desprender del código fácilmente.

Definitivamente.

[...]

> > > > - que use tecnologia (lenguaje, etc.) que provee una empresa
> > > > "importante" del rubro como IBM, Oracle, Sun o Microsoft?

> > > Que use la mejor opción para resolver los requirimientos.

> > Como determinas cual es esa? Desde el punto de vista de la comodidad
> > del desarrollador? Del usuario? De quien lo mantendra luego? Del que
> > provee las herramientas (al que le conviene cobrar lo mas caro posible,
> > claro)?

> En general, en mi experiencia, no hay muchas opciones al respecto, casi
> siempre el entorno te encamina hacia una tecnología.

Cierto, hay (natural y necesaria!) inercia de "sigamos con lo que
conocemos", pero esta la ley de Moore: A los 5 an~os definitivamente estas
haciendo cosas completamente diferentes, el problema es como llegamos
alla...

>                                                        Además que para
> este tipo de cosas no conviene ponerse inventivo, a la larga provoca mas
> dolores de cabeza para todos.  Es muy tentador poner en practica "la
> ultima tecnología aprendida" pero con la experiencia se ve que hay que
> mezclar el ser conservador y al mismo tiempo explorador de nuevas
> tecnologías.

Es facil decirlo, dificil de llevar adelante...

> > Hay que considerar la ultima hornada de TLA y buzzwords? Realmente la
> > ultima pomada de "desarrollo por telepatia con los alienigenas de los
> > planetas recien descubiertos" es mejor que las tradicionales o no? Como se
> > determina eso (particularmente antes que la moda haya sido reemplazada por
> > la de la siguiente temporada)?

> No necesariamente son modas.  En vez de descartar una cosa por otra, se
> van encontrando mejoras, yo lo llamaría evolución.

/Hay/ modas, que ciertamente algun aporte hacen, pero definitivamente no
son 100% aplicables a 100% de las situaciones. Nuevamente; cual es la parte
que realmente aporta y cual es pura farandula, cual parte puedo integrar de
forma que haga aporte en mi proceso actual y cual resulta contraproducente,
en cual situacion es aplicable y cuando no, cuento o no con las condiciones
internas (personal, cultura, herramientas, ...) para trabajar asi, el
entorno (clientes, ...) funciona bien con este esquema, ...

> Por ejemplo hasta hace poco era natural pensar en aplicaciones con el
> contenido+presentación generado en el servidor (php/asp/jsp, etc), eso
> tenía ventajas y desventajas.  Hoy en día es posible hacer aplicaciones
> que corren en el lado del cliente, eliminando las desventajas del modelo
> previo, pero manteniendo y ampliando sus ventajas.

Mish... "cliente-servidor" le llamaban a /esa/ pomada en los '80 ;-)

[...]

> > > ¿¿¿ Cual seria un buen punto de partida para tener un empresa que cree
> > > sw de calidad ???

> > Leer a conciencia la literatura /seria/ al respecto (no, no son las cosas
> > que se publican bajo "Ingenieria de Software" precisamente; son clasicos
> > como el libro de Brooks y lo que han publicado Kernighan, Ritchie, Aho,
> > Plaugher, Bentley (la tropa de AT&T tras Unix) y los BSDistas originales;
> > ver los comentarios sobre "buen gusto" de Linus Torvalds, Alan Cox, Al Viro
> > y algunas otras luminarias similares). Conocer los famosos modelos de
> > madurez de desarrollo. Estos ultimos entenderlos lo suficiente para saber
> > que debieran ser quemados ritualmente en una pira [Aportan mucho mas a
> > generar frondosa documentacion y burocracia que buenos resultados].

> Depende.  El modelo CMMI por ejemplo habla de cosas que deberias tener
> como parte de tus practicas, pero queda de tu parte la forma en que las
> implementas.  En general las prácticas son cosas que te ayudan y no se
> trata de simple burocracia, no creo por ejemplo que alguien en su sano
> juicio encuentre que hacer seguimiento de bugs formal es una burocracia,
> y cuando me refiero a formal no estoy hablando de llenar un monton de
> formularios inútiles, estoy hablando de las mismas prácticas que se
> llevan en el desarollo de código abierto.

Disculpa, estas hablando del _espiritu_ de CMMI. En la practica, para
_certificarte_ en CMMI tienes que tener un monton de papeles que demuestran
que reportaste el bug, que quedo registrado, que hay "alguien" responsable
de revisar que los bugs se reporten, ...

Como lo que vi alguna vez en un aeropuerto: Ibamos por un amplio pasillo, y
de repente esas cuerdas para cerrar el paso + guardias. Un fenomenal taco,
reclamos, ... consultas posteriores indicaron que era "por la certificacion
ISO", no se permite que se mezclen pasajeros que vienen llegando con los
que van saliendo. Solucion: Pasan igual por pasillos que se cruzan, pero
los segregamos con guardias y barreras temporales. Se certifica "de
calidad", pero es cualquier cosa ridicula lejana de lo que cualquiera
entiende por eso.

Demasiadas de las certificaciones son, como alguien dijo, "We do everything
following the prescription to the letter, but we still just make shit".

[...]

> > Tener presente que la diferencia de productividad entre un desarrollador
> > malo y uno excelente puede facilmente superar las 100 veces.

> También hay que considerar que un desarrollador excelente no le va a ser
> atractivo trabajar en tareas triviales, tener sólo desarrolladores
> excelentes hace que nadie sea capaz de llevar a cabo ese tipo de tareas.

Para eso hay computadores... y la diferencia entre el excelente y el
mediocre es que el excelente sabe usar las herramientas.

> Personalmente creo en un mezcla de ambos, en donde un conjunto de
> excelencia se encarga de la infraestructura, y otro grupo se encarga de
> "las terminaciones".

"Chief programmer team" le llamaban a eso...  
-- 
Dr. Horst H. von Brand                   User #22616 counter.li.org
Departamento de Informatica                    Fono: +56 32 2654431
Universidad Tecnica Federico Santa Maria             +56 32 2654239
Casilla 110-V, Valparaiso, Chile 2340000       Fax:  +56 32 2797513