Niveles de calidad: el agujero en las metodologías de software
AbrahamFrancisco Morero Peyrona (peyrona) y un servidor hemos escrito un artículo reflexionando sobre lo que, desde nuestro punto de vista, es la principal carencia de las metodologías de desarrollo de software (tanto las ágiles como las tradicionales): la gestión del nivel de calidad que se debe alcanzar en un desarrollo.
Todas las metodologías de software parecen estar diseñadas para alcanzar una calidad máxima en todos los desarrollos. Es como si todos nos estuviésemos engañando a nosotros mismos diciendo que nuestro objetivo siempre es desarrollar software de la máxima calidad posible. Sin embargo, recursos temporales, económicos y de personal limitados, así como la propia naturaleza de cada proyecto de software, hacen que esto no siempre tenga sentido.
El artículo hace la reflexión de que no todo el software que desarrollamos requiere la misma calidad. Defiende esta posición con ejemplos, y proporciona una serie de "reglas del pulgar" a aplicar a distintos arquetipos de proyecto de software que, según nuestro punto de vista, típicamente requieren niveles de calidad diferentes. Os dejamos aquí el artículo:
Niveles de Calidad: el agujero en las metodologías de software.
Sobra decir que los autores estamos muy interesados en cualquier tipo de crítica, constructiva o destructiva, acerca de las ideas que presentamos en el documento.
Reader Comments (38)
muchas gracias por el análisis. realmente interesante.
Buenas,
Por lo que he ojeado por el momento esta genial.
Por fin un estudio de este tipo desde un punto de vista practico y sobre todo realista... Que falta hacia!
Yo personalmente estoy bastante harto de tanto teorico que al final nunca se mancha las manos y que como mucho solo tiene experiencia en codificar sus propios proyectos megacool en solitario (con las mejores practicas, tdd, superpatterns, por supuesto)... que no utiliza nadie.
Gracias!
Gracias a vosotros por vuestras felicitaciones :)
Comentar que más que un "estudio", que parece que implica haber recopilado datos y analizarlos, esto al final no son más que opiniones de dos personas, ni más ni menos. Si os resulta útil a los demás, pues genial.
La única "crítica", si es que se le puede llamar así, que haría sería al concepto "Regla del Pulgar", y no porque sea una traducción del inglés, sino porque no se usa en castellano, y su sentido, tanto en inglés como en otros idiomas, puede no ser el adecuado.
Lo más aproximado en castellano a "regla del pulgar" sería "medir a cuartas", porque la idea original tras esa expresión es: falta de precisión en la medida, o medida aproximada.
Aunque en el inglés moderno se ha popularizado con el sentido de "regla elemental".
Lo cambiaría por "Sentido Común", porque ese es el tema de fondo del artículo, y lo que le da su mayor valor. Y, además, se entiende perfectamente en castellano lo que se pretende comunicar.
Creo que hace falta más y mejor sentido común, apoyado en un conocimiento detallado del lenguaje, y menos hipérboles, tanto academicistas como comerciales. Este artículo abunda en el primero, y rehuye, con el mejor criterio, las segundas.
Solo hecho en falta, a menos que se me haya pasado por alto, una herramienta de análisis estático como PMD. Siempre la he encontrado más manejable que Checkstyle.
@choces Respecto al tema de las "Regla del Pulgar", yo prefiero ese término sentido común. Sentido común implica algo que es obvio o que conoce (casi) todo el mundo, lo cual no tiene que ser necesariamente así como una regla del pulgar. De todos modos, el principal responsable de ese término es mi compañero peyrona, al cual le encanta.
Por otro lado el documento no hace mucho énfasis en herramientas particulares porque pretende ser agnóstico respecto al lenguaje de programación. Cuando se habla de alguna herramienta se pretende ser puramente ilustrativo. Pero, creemos, que las ideas que hay detrás del documento las recomendaciones se pueden aplicar a cualquier lenguaje de programación.
Parece que el enlace esta roto, no me lo puedo descargar
A mí me funciona perfectamente:
http://www.javahispano.org/storage/documentacion/Niveles%20de%20Calidad%20el%20agujero%20en%20las%20metodologas%20de%20software.pdf
¿Alguien más tiene problemas?
Funciona sin problemas
Saludos
Excelente documento, habéis dicho lo que muchos desarrolladores pensamos.
gracias por el aporte comenzare a leerlo
Antes de la publicación hemos discutido sobre este tema Abraham, Peyrona y yo, ellos ya conocen mi opinión pero como el objetivo es que se debata aquí pues ahí va.
En grandes rasgos estoy de acuerdo con el texto salvo en un aspecto esencial: el documento parte de la premisa de que el nivel de calidad depende de la naturaleza del proyecto (por ejemplo un framework o un CRUD), salvo casos bastantes obvios, estoy poco de acuerdo con esa tesis, el nivel de calidad en mi opinión lo acaba decidiendo el cliente, explícitamente e implícitamente.
Brevemente:
Si un proyecto hay que hacerlo en "2 días" el resultado será una basura, da igual cual sea la naturaleza del proyecto y lo preparado que esté el equipo.
Si estamos haciendo un CRUD que mueve miles de millones al cliente le interesará unos niveles de calidad (eso supone recursos, tiempo etc) que soñaría la micro-empresa de turno que está haciendo el framework que apenas usan cuatro gatos.
Por otra parte hay un cierto mito de que un framework debe ser de buenísima calidad y un CRUD no merece tanta calidad, quizás sea al contrario, la mediocridad y los fallos del framework nos los comemos nosotros, los programadores, y muchas veces tenemos que luchar "contra el framework" precisamente para que no se manifiesten en el CRUD que lo usa.
Acabo de leer:
"Couchbase Community Editions are best for non-commercial developers... There are no constraints on using these binaries on production systems, but they have not been subjected to the iterative test, fix and verify QA cycle that is a part of the Enterprise Edition release"
http://www.couchbase.com/couchbase-server/editions
Tened seguro que Couchbase CE se usará en "misiones críticas" para hacer CRUD en donde se exija 0 problemas.
Lo primero decir que el texto da buenos consejos sobre todo en la parte de "Reglas del pulgar", como siempre, estos son generales y hay que adaptarlos a casos concretos, pero como directrices están muy bien.
Sobre el nombre "Reglas del pulgar" también estoy de acuerdo con algún comentario de que no es demasiado adecuado, algo como "Directices prácticas" o similar sería más adecuado.
Sobre la idea general del texto, al final, yo creo que todo el que se dedica al desarrollo sigue más o menos la siguiente regla para aplicar calidad:
Si el tiempo y el presupuesto lo permite (lo decide el cliente normalmente)
Aplicar calidad de mayor a menor a
Proyectos que van a usar otros desarrolladores
Proyecto que solo van a usar los usuarios
Chapuzillas (vease aquí script, aplicaciones para automatizar cosillas puntuales,...)
sino
Se hace lo que se puede
Pero en general, un buen documento, ¡enhorabuena!
En mi opinión, los motivos para exigir calidad siempre son el entrenamiento y la costumbre.
Para hacer buen código hay que entrenar mucho y, por el contrario, es muy fácil acostumbrarse a hacer mal código.
Es como cuando a los niños les dicen que tienen que sentarse en una postura adecuada para cuidar su espalda. En realidad, la espalda de los niños necesita poco cuidado, pero si desarrollan esos malos hábitos lo pagarán cuando sean mayores.
Yo siempre he intentado hacer las cosas lo mejor posible pero hace años trabajé en un entorno donde todo era hacer ñapas y chapuzas y un día me di cuenta de que estaba haciendo ALTER TABLEs en producción sin backups. Ese día decidí cambiar de empresa.
Es muy fácil acostumbrarse enseguida a hacer ñapas, de ahí la lógica de hacer buen código incluso para los scripts.
Pues me ha gustado mucho. Sea la regla del dedo o el sentido comun lo que se describe en ese documento, que en estos tiempos en los que la unica manera de no ser mediocre es escribir miles de lineas de tests antes de escribir ni una sola linea de la aplicacion o usar una docena de siglas, que alguien diga que no todas las aplicaciones son iguales, o incluso que hay algunas para las que los test son una perdida de tiempo es bastante refrescante.
Al leerlo no he tenido la sensacion que he tenido al leer otros documentos de "este no ha visto el mundo real en la vida". Pero en ese documento se hace mencion de los requisitos cambiantes (que en otros sitios se ve que son abundantes, detallados y estaticos, pero que nunca me los he encontrado asi), o de como una pierna rota te descabala el desarrollo (la gente importa y no es lo mismo que las cosas las haga Juan a que las haga Pedro). O la cuestion presupuestaria, que por ahorrar en sueldos o en formacion te puedes encontrar con gente que no sabe lo que es la clausula WHERE de SQL y se lee la tabla entera y filtra resultados con Java (veridico), que estas cosas no pasan en las presentaciones.
Lo unico que añadiria es que a veces puede no haga falta ni script, que a mano es mas rapido, y que en cualquier caso, los comentarios en el codigo son necesarios (yo tengo memoria de pez), pero por lo demas, me ha gustado mucho.
Yo no os di el feedback a tiempo, así al menos ahora os comento algunas de mis impresiones sobre el texto. No estoy de acuerdo con la idea de diferenciar la calidad en función del tipo de proyecto, para mi sólo hay dos niveles:
- Código para tirar, este lo hago en la herramienta mas rapida que tenga y de la forma más rapida posible, probablemente lo mejor un pequeño script en algún lenguaje interpretado o incluso escribo comandos en un REPL y listo.
- Código que no voy a tirar, este le hago lo mejor que puedo siempre, y lo mejor que puedo es lo mejor que puedo, es probable que lo coja otro programador mejor y le parezca una birria. Justifico esto un poco más:
* No es cierto que se tarde más en hacerlo bien que en hacerlo mal. Es una cuestión de habilidad del programador, ni con todo el tiempo del mundo un mal programador escribirá buen código.
* Con el cliente no discuto niveles de calidad, con el ciente discuto alcance. Que en el fondo es en muchos casos lo mismo que habéis puesto en el documento pero con otro enfoque. Por ejemplo, en el caso de un framework, decís que hay que hacer una mejor documentación o decís que hay que hacer aplicaciones de ejemplo. Totalmente de acuerdo, pero para mi esto no es "calidad" para mi esto es alcance del proyecto, son historias de usuario que añado a mi pila. la calidad es para mi "como hago las cosas" y el alcance es "que cosas hago", hacer o no una aplicación de ejemplo en mi opinión encaja en lo segundo, es parte de mi entregable no parte de mi proceso para construirlo.
* Motivación, si motivación, os recomiendo la lectura de Drive (o ver la charla http://www.ted.com/talks/dan_pink_on_motivation.html que se tarda menos y dice casi lo mismo :P). Uno de los tres factores fundamentales de motivación es "la maestría", en otras palabras, "el orgullo por lo que se hace". No hay forma más facil de cargarse la motivación de un equipo que pedirles que lo hagan peor de lo que saben.
Luego algúnos temas menores con lo que no estoy de acuerdo:
- Habláis de TDD como tecnica de pruebas, y por eso no entendéis bien donde encaja. Es una tecnica de diseño, no se puede forzar a ningún equipo a usarla ni se puede forzar a quien la usa a no usarla, porque precisamente, es una forma de pensar, siempre lo digo, la primera T debería ser una E (Example Driven Development). TDD != test automáticos.
- No pidáis cosas como "cobertura" de test porque correis el riesgo de que os den cobertura, me explico:
public void testWhatever() {
try {
SUT.doWhatever()
assertTrue()
} finally {
assertTrue()
}
}
A lo mejor os parece exagerado, a mi también me lo parecia, pero como ya lo he visto unas cuantas veces... precisamente hoy hablaba con un compañero freelance que trabaja entre otros para una gran empresa naranja y que precisamente piden un 85% de cobertura para sus desarrollos, pues el resultado es ni más menos lo que tenéis arriba. (lo mismo con normas tipo checkstyle o pmd). No digo que estas herramientas no sean utiles, pero siempre utilizadas como "avisos" para aprender a mejorar, nunca como controles.
- Otra cosa con la no concuerdo es con la parte en la habláis de hacer una buena ingeniería de requisitos al inicio del proyecto para firmar un documento donde no se escape ni un pelo y evitar futuros problemas. Esto en mi opinión ni ha funcionado ni funcionará nunca, no funciona para el proveedor y sobre todo no funciona para el cliente. Se plantea el desarrollo de software con una actividad donde cliente y proveedor están enfrentados desde el principio y se pierde MUCHISIMO tiempo en construir barreras de defensa (los requisitos como contrato defensivo por si nos dicen algo que falta o que sobra). En mi opinión esta forma de desarrollar esta abocada al fracaso siempre, evidentemente ya se que "en el mundo real bla,bla,bla" las cosas funcionan así y tal y pascual, pero si nos conformamos con esto no cambiarán nunca. Casos en los que esta relación de "enemistad" cliente/proveedor no existe y no mencionaís:
- Desarrollo de producto: que es lo que yo hago ahora mismo. Es lo que hace google por ejemplo. O spotify que hace poco leia un documento sobre su organización interna más que interesante. En estos mundos no es necesaria esa "arma" defensiva, se desarrolla software iterativamente para adaptarse a lo que el mercado exige. Decía Mike cohn que si un año despues de escribir los requisitos no habían cambiado quizas es que no estabas muy atento al mercado o al feedback de tus usuarios.
- Desarrollo para terceros en iteraciones cortas: en esta situación te olvidas de las "armas de defensa" y te pones a trabajar desde el primer momento. Los contratos permiten que cualquiera de las partes se desvincule en cualquier momento si no están satisfechos con el trabajo y se desarrolla con entregas muy cortas y fundamental, en un clima de CONFIANZA no de enfrentamiento. De nuevo alguno pensará "esto es ciencia ficción en el mundo real bla,ba,bla...", pues bueno, yo en el mundo real conozco unas cuantas empresas que trabajan de este modo y que no aceptan además trabajar de otro. Se trata de cambiar la relación de proveedor/cliente por una relación más similar al partnership tecnológico.
Como reflexión final, decía el autor de CMMI que "la calidad de un desarrollo depende de la calidad de los procesos empleados para construirlo", yo creo que la realidad es bien distinta "la calidad de un desarrollo depende de la calidad de las personas que lo construyen". Cualquier intento de definir un proceso o normativas de calidad en función de lo que sea suele servir para bien poco. Si muchas empresas en lugar de gastar muchos euros en "departamentos de arquitectura" que definen normas, procesos y demás historias se gastarán el dinero en cambiar su politica de contratación y de formación otro gallo les cantaria.
Si es que no es tan difícil, coger el ejemplo de google, de microsoft incluso una patría; de tuenti, y ver como son sus políticas de contratación comparadas con las de alguna consultora de medio pelo de las de por aqui. Es AQUI y no en los procesos donde esta la raiz de las diferencias de calidad entre unos y otros.
Estoy muy de acuerdo en muchas cosa que dices Alfredo, pero no te olvides que estás en una empresa de producto (yo también).
Respecto a temás de contratación me temo que ni tu ni yo seriamos contratados en Tuenti segun tengo entendido, creo que se nos pasó el arroz para algunos, el mundo real es tan real que cuesta encontrar ejemplos que no sean contradictorios :)
No se me olvida que estoy en una empresa de producto, por eso he puesto que es un caso distinto que me faltaba en el documento, pero si lo analizas un poco ¿porque es mejor una empresa de producto que trabajar para terceros?, ¿si te tomaras el trabajo para esos terceros como tu propio producto no sería lo mismo?.
El problema es que se quiere contratar desarrollos de software como quien va al ikea a comprar una mesa, plazo cerrado/precio cerrado/alcance cerrado, y así no hay manera de hacer nada bien. Incluso aunque hagas lo que pone en los requisitos, lo más probable es que en cuanto empiecen a usar el software pidan miles de cambios porque por primera vez los usuarios DE VERDAD y no los que escribieron los requisitos usan el software. Me gusta mucho la famosa frase "no tienes que hacer lo que el cliente pide, tienes que hacer lo que el cliente necesita".
Salvo en proyectos donde los requisitos sean muy evidentes y la dificultad sea más bien tecnologica (ej: quiero hacer un buscador de internet como google, es facil de entender, complicadillo de hacer) esto no funciona. Lo normal y más aún en el soft de gestión es que la verdadera dificultad este en entender que es realmente lo que quiere el cliente, y esto en mi opinión sólo se consigue con desarrollos iterativos y estando muy cerca del usuario final. Lo demás es una mentira que dura hasta que el plazo inicial se acaba, en ese momento se entrega lo que sea (que se puede ajustar o no lo "pedido" pero seguro que no se ajusta a lo que hace falta), y entonces se entra en la fase de "mantenimiento" que en realidad viene siendo lo mismo que un desarrollo iterativo pero con todo el mundo cabreao.
Lo de tuenti era un ejemplo, porque su proceso de selección es, en comparación con la tipica consultora, mucho más exigente, y el nivel de calidad también es, de nuevo en comparación con la misma tipica consultora, bastante más elevado. Es simplemente por poner un ejemplo cercano de que la calidad esta en las personas y no en los procesos, que luego tengan chorradas con la edad y tal pues la verdad no lo se, aunque me consta que hacen entrevistas a gente de más o menos mi edad, tu es que estas ya mucho más mayor jose maria :P (es broma, es broma)
Que yo esté ampliamente de acuerdo contigo no implica que el "mundo real" lo esté, ahora bien hay signos de que el "mundo real" está cambiando :)
No, todavía no me han llamado de Tuenti y eso que sus empleados usan una herramienta de la que yo tuve mucho, mucho que ver, y eso que me gusta Lady Gaga :)
Fin por mi parte de ese tema (me cabrea mucho)
Tan real es everis como google, no se de donde viene esta asociación "mundo real" con hacer las cosas mal. la preguntas son ¿hacia donde queremos ir?, ¿vamos a hacer algo para cambiarlo o nos vamos a quedar maldiciendo nuestra suerte?. Cada cual tendrá sus respuestas, yo desde luego tengo las mias.
Hola Alfredo,
Tu dicotomía de "código para tirar o código bueno" me parece irrealista y demasiado simplista. Al menos yo, puedo "calibrar" de un modo mucho más fino mi metodología de desarrollo para adaptarme a distintos tipos de proyectos que considero requieren diferente calidad. Y sí, sí que creo que existen esos proyectos. Si tú me dices que el típico CRUD de aplicación de Internet requiere el mismo nivel de calidad que el framework de collections de Java o como el software que corre en un marcapasos (entendiendo calidad en sentido extenso como se hace en el documento, incluyendo cosas como número de test, revisiones por parte de otros programadores, documentación en el código, documentación externa…) pues entonces dejamos de discutir en los vamos a tomar una caña porque está claro que nunca nos vamos a poner de acuerdo en esto.
Si el CRUD empresarial se desarrollase como el framework de Collections de Java o el software de un marcapasos, entonces incluso una pequeña aplicación CRUD empresarial tendría costos siempre por encima de los 10 millones de euros. No es viable, y no tiene sentido, usar el mismo proceso de desarrollo en estos tres escenarios.
Por otro lado, algunas de tus críticas creo que surgen del sesgo particular que tú tienes por tu experiencia trabajando en proyectos pequeños y medianos (eso sí, más grandes que en los que yo he trabajado). Aquí es donde el compañero Peyrona ha aportado una visión y una contribución muy importante a este documento. El ha estado involucrado en mayor o menor medida en proyectos de software realmente grandes (Netbeans, por ejemplo, o el propio Java). Cuando el número de desarrolladores en tu proyecto de software se cuenta por cientos, o incluso por miles, uno sí necesita herramientas automatizadas para producir ciertas métricas y tener una idea general de cómo va el proyecto. Y, por más excelente que sea el proceso de contratación y por más que uno se esfuerce en contratar a buenos desarrolladores, al contratar a cientos siempre va a haber ovejas negras. La estrategia de contratar a buena gente y confiar en ellos, funciona cuando tú eres capaz de recordar el nombre de cada uno de ellos y sabes sí están casados, tienen novia o tienes hijos. Cuando no eres capaz de recordar esa información, deja de funcionar. Cuando uno está en esta situación, es cuando la frase del autor de CMMI se aplica.
Una de las cosas que yo no entiendo completamente del documento, porque es hija de la experiencia de peyrona, es el tema de hacer esa excelente ingeniería de requisitos. Yo nunca me he visto en una situación similar; y nunca he tenido la experiencia de pasar por las cosas que el documento describe. Pero yo nunca he trabajado en proyectos con cientos de personas, con presupuestos de cientos o incluso miles de millones de euros. Comprenderás que cuando esas son las cantidades que hay encima de la mesa "la confianza" no va a ser suficiente. No creo que Airbus esté por la labor de subcontratar el desarrollo del software que controla el A380 a una empresa y le diga "vamos a confiar el uno en el otro; no hacemos un contrato pero yo confío en que tú vas a hacer el mejor desarrollo de software posible, y espero que con el software que tú me des el final el avión vuele de un modo seguro". Obviamente, es completamente inconcebible ese escenario. Airbus va a firmar un contrato de cientos de páginas con esa empresa especificando exactamente como debe de funcionar cada uno de los subsistemas del avión, el nivel de tolerancia a fallos en la robustez de cada pieza de software, su rendimiento, el consumo de potencia que retira para ejecutarse en los procesadores…
Por último, aunque es redundante insistir en esto, decir una vez más que las reglas del pulgar son reglas del pulgar. Una regla del pulgar es que un chino suele trabajar más horas al año que un español. Esto no quiere decir que no haya un español que trabaje más que cualquier chino. O que que un chino pueda ser más bago que cualquier español. Las reglas del pulgar tienen un montón de excepciones, y hay que adaptarlas a cada caso concreto. Por ejemplo, un caso que discutí con José María es el de Liferay, un framework que no tiene una calidad demasiado elevada. Pero ellos tienen la ventaja de que no tienen competidores en su nicho que tengan unas características similares a las de su producto (especialmente, la parte de ser gratis, o al menos tener un coste más bajo que las alternativas comerciales que tienen funcionalidad equivalente). Por eso se pueden permitir un nivel de calidad más bajo y la gente traga con él.
Muy interesante el hilo, últimamente javaHispano parece recuperar "buenos tiempos pasados".
Abraham por mi parte como decía más arriba "salvo casos bastantes obvios", algunos ejemplos que pones son de los "bastante obvios": marcapasos y AirBus = responsabilidad civil, vidas por medio, requisitos y objetivos MUY claros, resultados claros y medibles... en donde es difícil no estar de acuerdo :)
NetBeans no es un sólo proyecto, es una miriada de proyectos, algunos son nucleares y ciertamente si esos funcionan mal apaga y vámonos, otros son de dominio totalmente independientes entre sí (dependientes eso si del núcleo) y es muy probable que no los uses nunca y su mediocridad afectaría a pocos y a veces se consigue tolerar (el "a pesar de"), a la hora de la verdad la grandeza de NetBeans (los componentes nucleares) está en pocas manos, si no es así que Peyrona me corrija.
Por otra parte el estado del arte del desarrollo software todavía está muy muy muy lejos de que un índice de cobertura y una batería de tests garanticen la calidad de un software, aunque ciertamente ayuda mucho mucho. Documentos de miles de páginas de requisitos y buenas intenciones no garantizan que los técnicos sean unos verdaderos artistas del S.O.L.I.D., no nos engañemos, hay miles de aplicaciones que internamente son una verdadera basura que funcionan a la "perfección". Eso respecto a la calidad (que yo mido fundamentalmente como calidad estructural la cual es precisamente la difícil de medir). Por otra parte no conozco ninguna metodología de captura de requisitos y de organización del trabajo que garantice que un sistema altamente asíncrono (muchos procesos asíncronos que deben coordinarse) sea una garantía de que el resultado sea muy bueno.
¿Que un buen documento de requisitos es totalmente necesario? Si pero:
1) Si acertara a la primera
2) Si se respetara (y a veces es conveniente que no se respete desde muchos puntos de vista).
Yo hace muchos años lei en un documento de requisitos de una web de empleo que los C.V. en formato texto se analizarían y a partir de él se extraerían los datos personales, su experiencia etc ¿LinkedIn os ofrece eso cuando os dais de alta? (por hablar de "alguien" que podría permitirse trabajar en ese tema).
Hay una realidad muy dura en el mundo del software: el que el encarga un trabajo y el usuario quieren X y que funcione bien y te dirán "búscate la vida", si las Collections de Java tienen errores y lo usas como excusa de comportamientos anómalos, el usuario te dirá "a mi que me cuentas es tu problema" y le tocará al programador bregar con dichos errores y evitarlos (los "workarounds").
No siempre puedes delegar en el usuario los problemas de tu software, no todo el mundo es Microsoft, el sentido común dice que una herramienta software, un framework debería tener una calidad perfecta, pero la realidad dice que lamentablemente a veces trabajamos con herramientas subóptimas y sin embargo, a pesar de ello conseguimos resultados de gran calidad (porque nos lo exigen), no tienes más que ver cuando se publica una versión nueva de la herramienta X y te listan con orgullo una larga lista de "bug fixes", pues no, no es para estar orgulloso, esos bug fixes han estado ahí antes dando por saco.
Últimamente por ejemplo me tengo que pelear con un "resize" de unos poquitos pixeles que hace el componente web de Android en la Nexus 7 pero que no ocurre en la misma versión del S.O. en cualquier otra tableta, esa chorrada te jode vivo cuando *necesitas* que el tamaño sea fijo una vez calculado (que es lo normal, no es mucho pedir) y dedicas buena parte de tus esfuerzos a "luchar" contra ese problema para que el usuario siga siendo feliz ajeno a tus problemas...
Respecto a Liferay... Abraham no cuentes nuestras conversaciones privadas :)
Abraham:
Insisto en que para mi no es cuestión de "calidad" sino cuestión de "alcance". Ya que hablas de proyectos muy críticos, recuerdo el caso de un proyecto para la NASA, lo hacían dos veces!, por equipos distintos, y luego los dos proyectos tenian que comportarse exactamente igual.
Para mi esto es añadir más actividades al proyecto no hacer esas actividades con un mayor o menor grado de calidad. Aqui creo que esta la diferencia. Evidentemente no para todos los proyectos tienes que seguir el mismo conjunto de actividades, pero cuando me pongo a nivel de por ejemplo cada clase que escribo no decido si hacerlo mejor o peor, lo hago siempre lo mejor que se. Incluso en el muy corto plazo, días, el mayor freno para la productividad son los atajos y el código cutre, la única forma de ir rapido es hacerlas cosas bien
PD: luego sigo jeje, que me dejo cosas en el tintero pero tengo una urgencia :P
@jmarranz
..como decía más arriba "salvo casos bastantes obvios", algunos ejemplos que pones son de los "bastante obvios": marcapasos y AirBus
Me alegra que al menos estemos de acuerdo en que existen esos casos obvios. Yo además argumento que la situación no es "casos obvios extremos" por un lado y "todo lo demás" por otro. Argumento que entre el software del marcapasos o del avión y el script que sólo se va a ejecutar una vez y se tira hay todo un continuo de niveles de calidad. Y que hacer un análisis de exactamente donde cae el proyecto que estoy abordando en ese continuo es un paso muy útil para decidir cuál va a ser la metodología de desarrollo.
… (sobre Netbeans) algunos son nucleares y ciertamente si esos funcionan mal apaga y vámonos, otros son de dominio totalmente independientes entre sí…
¡Caray! Esto suena a aceptar la hipótesis que peyrona y yo planteamos en el documento. No todos los proyectos necesitan la misma calidad :).
Estoy de acuerdo en que un proyecto gordo se va a modularizar de algún modo. Aún así siguen siendo necesarios mecanismos de control más formal que en un proyecto donde todo el mundo conoce a todo el mundo.
… el estado del arte del desarrollo software todavía está muy muy muy lejos de que un índice de cobertura y una batería de tests garanticen la calidad de un software…
Totalmente de acuerdo. Pero como tú dices, son mejor que nada.
… el que el encarga un trabajo y el usuario quieren X y que funcione bien y te dirán "búscate la vida", si las Collections de Java tienen errores y lo usas como excusa…
Con este párrafo estoy totalmente de acuerdo, pero no termino de ver la relación con la conversación o el documento. El software no es perfecto y a veces tiene fallos, incluso aquel en el cual se trata de llegar a la máxima calidad. Ha habido aviones que se han estrellado por culpa del software de navegación. Esto no hace que deje de ser verdad el hecho de que el software de inauguración de un avión deba ser desarrollado con el objetivo de alcanzar la máxima calidad posible.
Sobre el tema de los proyectos grandes, cierto que mi experiencia esta en proyectos pequeños-medios (20 personas a lo sumo). Sin embargo sigo pensando que los procesos o las metricas no empiezan a funcionar si los proyectos son más grandes, ¿si estas técnicas no funcionan en pequeños equipos que me podría hacer pensar que en proyectos grandes va a escalar bien?.
Os pongo el ejemplo de spotify: https://dl.dropbox.com/u/1018963/Articles/SpotifyScaling.pdf, en este documento describen cual es su organización. Spotify es un proyecto que ya podemos considerar "grandecito" con +100 (creo que rondan los 200 pero no lo puedo asegurar) desarrolladores. Es un sistema con muchas cositas y con requisitos realmente complejos de escalabilidad y que desde el punto de vista técnico se puede considerar exitoso (clientes contentos, yo uno de ellos).
Luego tenemos proyectos grandes gestionados con procesos (metrica 3 por ejemplo) como el famoso proyecto para gestionar los impuestos madrileños que lleva AÑOS y no tienen nada funcionando, o la eterna automatización de los expedientes para los juzgados o ... Proyectos grandes, donde el foco esta en los procesos y luego se contrata a un ejercito de becarios o programdores junior, el resultado en estos casos es siempre el mismo.
Por eso en mi opinión el foco hay que ponerlo donde radican las diferencias, y las diferencias radican en las personas. Lo que tiene sentido es coger lo que funciona en un proyecto pequeño y escalarlo, no coger lo que no funciona en un proyecto y escalarlo con la esperanza de que funcione.
@alfredocasado bueno, si para ti "una actividad" del proyecto es, por ejemplo, el hecho de que la calidad de este software haga necesario que cada línea de código sea revisada por un segundo programador, pues vale, entonces incrementar calidad puede verse como incrementar actividades. Entonces, digamos que "hay proyectos que requieren más actividades que otros", en vez de decir que "hay proyectos que requieren más calidad que otros" XD
Promete el asunto
@Abraham
Bueno justo ese ejemplo no me vale, las revisiones de código ahorran tiempo en el corto plazo (días o semanas) con lo que para mi es obligatorio hacerlas en cualquier proyecto de más de una semana duración (vamos que no es de usar y tirar). O bien revisiones o bien pair programming (con lo que el equipo decida que se siente más comodo) y por supuesto siempre collective code ownership (es decir, todo el mundo toca cualquier parte del proyecto). Pero de verdad, es que esto AHORRA TIEMPO, no tiene sentido no hacerlo. Otra cosa es hacer un simulador del airbus, o hacer un conjunto de ejemplos y documentación exhaustiva de una librería, esto son más tareas a mi proyecto.
Creo que con "calidad" gente diferente entiende cosas diferentes, por ejemplo, sólo estamos hablando de "robustez" (hacer cosas que funcionen), pero que pasa por ejemplo con el UX?, cuando cojo un coche la calidad no es sólo que ande, es que sea comodo, bonico etc,etc. ¿Esto lo obviamos en el software?. ¿Hacer el interfaz más "usable" seria cuestión de calidad o de alcance?. Yo prefiero enfocarlo como un tema de alcance, porque así me es más facil explicarle al cliente "primero lo haremos así", "luego le añadimos tal opción más comoda de usar", "luego...", así puedo parar el proyecto en cualquier momento y tengo algo que al menos funciona. Si lo enfoco como calidad, la cosas son binarias, o estan o no están, y no puedo ir añadiendo esa "calidad" de forma gradual a mi proyecto.
Otra cosilla que se me olvido antes. Las metodologías ágiles no acaban en scrum, que ultimamente parece que a fagocitado a cualquier otra (excepto quizá XP). Otra metodología que es parte de la familia "agil" es crystal, en realidad se trata de un conjunto de metodologías o recomendaciones que varian en función del tamaño del proyecto (clear, orange... más tamaño más oscuro el color).
En estas metodologías se pone el foco en las personas en lugar de en los procesos y los colores más oscuros basicamente son estrategias para escalarlas a equipos más grandes. La cosa es que no es una metodología que haya tenido gran repercusión (salvo algunas practicas como el famoso 'walking skeleton' que pertenece a esta metodología) y puede ser dificil encontrar información sobre algo que no sea crystal clear (que tiene un libro publicado, de los que merece la pena leer).
http://en.wikiversity.org/wiki/Crystal_Methods
Y en un proyecto en el que solo hay un programador ¿quien revisa su codigo? Si el proyecto debe durar un par de semanas, ¿cuanto tiempo se dedica a escribir tests de unidad? ¿Y a diseñar una aplicacion con inyeccion de dependencias o el ultimo paradigma/framework de moda?
Porque aunque no lo creais, hay muchos proyectos de esos y no me refiero a scripts guarreras que se tiran y se olvidan, si no a cuadros de mandos, informes, migraciones, demonios... cosas que no son tan serias como un marcapasos porque no se muere nadie pero que si son tan serias como una aplicacion de tarjetas de credito que va a mover millones de euros, porque de hecho pueden mover millones de euros o dar informacion que se usa para tomar decisiones. Y por supuesto, mucho mas serias que Tuenti o Facebook (que en realidad solo sirven de ejemplo si empezamos a hablar del volumen de datos que gestionan) que si se caen no pasa absolutamente nada.
No todo es web. De hecho, ¿cuantas de las aplicaciones realmente importantes se hacen siguiendo las ultimas tendencias? Y al decir importantes me refiero a esas que hacen que dejen de funcionar los cajeros automaticos, los telefonos moviles o los aeropuertos. ¿No sera que pasamos mucho tiempo leyendo articulos de la wikipedia sobre nuevas arquitecturas, principios, paradigmas y frameworks que solo se aplican a un unico tipo de aplicaciones bastante reducido y caemos muchas veces en sobreingenieria? Yo creo que la regla del dedo esa de la que hablais consiste en aplicar el esfuerzo en arquitectura adecuado a cada proyecto y pasar mas tiempo pensando en que haga lo que tiene que hacer que en pensar como le gustaria a Martin Fowler que estuviera hecho. Porque ademas, casi nunca oigo hablar de rendimiento o consumo de memoria.
@nilogj
Evidentemente si el proyecto es de un sólo programador la regla de que siempre se revise el código entre varios es un absurdo, pero esto es de cajón de madera, no creo que haga falta explicarlo. Sobre el tiempo dedicado a los test, lo digo una y otra vez, cuando se supera la curva de aprendizaje de TDD no se tarda más, sois libres de creerlo o no, como con argumentos no os voy a convencer jamás sólo os puede decir que alguna vez os senteis al lado de alguien que domine el tema durante un par de jornadas de trabajo y lo mismo cambia vuestra visión del asunto, si alguien quiere hacerlo conozco unas cuantas empresas que están encantadas de hacer desk surfing.
Sobre "las arquitecturas", personalmente creo en las arquitecturas incrementales, no en dedicar un tiempo inicial a montar una arquitectura del copon sino más bien lo contrario, dedicar el minimo tiempo a montar lo justo y necesario para que ande siempre con el criterio de "lo más simple lo mejor" y luego ir añadiendo complejidad cuando el proyecto lo exija, nunca antes.
Claro que no todo es web, de echo la mayor parte del código de facebook (por seguir con el ejemplo) no tiene nada que ver con la web que es sólo el UI final de un sistema enormemente complejo. Y eso de que no pasa cuando se cae... hombre no se muere nadie claro esta, ¿pero sabes la pasta que se pierde?, ¿es más importante la aplicación de tarjetas de credito que esto?, pues habría que echar cuentas, yo no lo tengo tan claro. No entiendo tu concepto sobre la "importancia" o "seriedad" de las aplicaciones, ¿evaluas por pasta?, ¿las web por defecto son todas poco importantes?. El día que se caiga google flipamos ¿esta es importante?
La calidad del SW en el modelo español, que no es precisamente innovador, es CERO PATATERO.
De hecho, aquí protestas por la calidad del código que ves y te expones a irte a la puta calle. Es así de simple. Y como nos conformemos, nos quedaremos en la cola de informática mundial.
Porque en España no mandan los informáticos, mandan los del negocio, y a los del negocio les importa que las COSAS FUNCIONEN. No les hables mucho de tecnología que los estresas.
Intentaré extender un poco más esta opinión, pero yo, como buen loco informático radical, espero que la realidad no me transforme / soborne en demasiado y sigue teniendo por ídolos a Google o Twitter y no a empresas españolas, a mi pesar.
Decir que el modelo español no fomenta precisamente la investigación. Aquí el pescado está muy vendido con las grandes compañías (que viven más del politiqueo), abrir una empresa es harto complejo y venderte como una empresa puntera en tecnología.... buf, si al alcalde del pueblo se la trae al pairo o no sabe bien como vendérselo a los votantes.
En fin paro que me estoy poniendo demagógico y no llego a ningún punto.
Lo que veo claro es: en España hay buenos desarrolladores, el modelo de trabajo no acompaña, la calidad no es importante, la innovación entonces baja, no somos referentes en el mundo, somos consumidores. Somos de la segunda división de la informática a nivel mundial.
Un saludo chavales,
Como se caiga una pasarela de pago, mucho dinero va a hacer Facebook...
Creo que los "ingenieros de software" (si es que tal cosa existe) todavía se resisten a admitir que las metodologías como la OO y sus evoluciones como la programación orientada a aspectos carecen de métodos de verificación, con lo cual es posible pasar por bueno cualquier porquería dentro del software a menos que se pruebe específicamente esa parte.
Intentaron justificarse con las "pruebas de cobertura", un engaño más... hasta un novel en programación se da cuenta de que el contexto de ejecución no es el mismo, pero a los "ingenieros" les interesa que el código se ejecute una vez para decir que está "cubierto" y se olvidan del tema.
¿Cuándo se van a convencer que la única salida viable que se ha inventado hasta ahora es la programación funcional?
Suerte con ego a los "ingenieros"
No se muy bien qué es lo que quieres decir JAV pero estoy tan cansado de oir los "egos" de algunos "ingenieros" del mundo de la programación funcional que me hace bastante gracia hablar de egos, y eso que el estilo funcional tiene para mi un lugar en el nivel micro y que realmente casi todo el mundo más o menos hace programación funcional en su día a día en cuanto utilizas inner classes (que se convertirán en closures dentro de poco) y haces algo de captura de contexto de llamadas.
No quiero salirme del tema aunque tiene que ver mucho con la calidad porque a la programación funcional se le atribuye el marchamo de "producir software de mejor calidad", pero hasta que no vea un toolkit UI de cientos (o miles) de clases en donde la gestión del estado lo es TODO, convertido a un estilo puramente funcional y que no huela a C...
@JAV hablar sobre el ego de los demás cuando uno basicamente esta diciendo que todo el mundo que no programa funcional es idiota es cuando menos osado...
Un par de cosas sobre el paradigma funcional:
- Que no haya que probar el código funcional porque se puede verificar formalmente es una simplificación de la realidad. La gente debe hacer librerías de testing para lenguajes funcionales como midje (https://github.com/marick/Midje) (del crack Brian Marick, más que recomendable su libro de programación funcional https://leanpub.com/fp-oo) por simple divertimento supongo.
- Sobre el estado, que los programas funcionales no tienen estado es cierto, que un sistema programado en un lenguaje funcional no tenga estado es rotundamente falso. Me explico, si tu sistema tienen que provocar algún efecto en el exterior, y supongo que así será en cualquier caso que vaya más alla del simple ejemplo o de una aplicación de calculo cientifico, eso ES ESTADO. Un ejemplo, si tienes que hacer una aplicación donde un usuario se registra y eso lo guardas en una base de datos, ESO ES ESTADO ergo las aplicaciones funcionales manejan estado, que el estado este fuera de tu código no implica que programar un sistema de forma funcional haga desaparecer algo que es una realidad: el mundo tiene estado.
Esto ultimo implica, que cualquier método de verificación formal tendría que incluir todas las posibles variaciones en el estado externo del sistema: bases de datos, ficheros, sistemas de terceros y un largo etc,etc. Por tanto, en la práctica, los métodos de verificación formal de la programación funcional son claramente insuficientes para asegurar la corrección de cualquier sistema medianamente complejo que quieras que genere algún efecto en el mundo real.
Vamos, que la programación funcional esta muy bien, tiene algunas ventajas evidentes sobre la programación OO o estructurada en muchos escenarios. Pero de esto a decir que es la solución a todos los problemas del software...
Pues claro que la calidad debe y puede variar dependiendo de muchos factores, entre ellos el cometido de la aplicación. Menudo invento el artículo.
De hecho en cualquier sitio que precie las metodologías y los procesos de construcción del software deben ser parametizables y por tanto variables. Igual que lo son en la elaboración de un pan o lo son en la elaboración de un coche.... por si alguien todavía anda en aquello de si el software es ingeniería o artesanía.
Más valía leer un poco más de procesos, de calidad y de mejora antes de restringir todo a cosas tan simples. Casi todo (incluido el artículo) está ya inventado...
@piratosafactory ¿podrías poner aquí alguna referencia que explique cómo adaptar alguna (cualquiera) metodología de desarrollo de software para obtener un determinado nivel de calidad?. Ni Peyrona ni yo conocemos ningún documento en esa línea. Y eso que entre los dos tenemos 40 años de experiencia en el mundo del desarrollo de software.
Hola, interesante artículo, mi concepto de calidad y como lo llevo a la practica es asi:
Para los programas de usar y tirar, no hago nada.
Si hacemos una prueba de concepto en una aplicación seria, la debemos tirar una vez finalizada, no reusarla. Ya que en una aplicacion seria, siempre hay que empezar por las pruebas, al menos las del 'happy path' si partimos de la prueba de concepto ya no haremos las pruebas correctas.
Para poder medir la calidad hay que saber cuales son los parametros a medir, tiene que existir un documento formal que lo especifique Yo los pongo en los casos de uso, que también mantengo con control de versiones. Los parametros que suelo medir además del caso de uso en si son:
1) correccion, que el programa haga lo que tiene que hacer. Para ello hay que documentar el caso de uso, saber que es lo que tiene que hacer el programa, codificar y probar, con pruebas de unidad.
2) mantenibilidad: codigo bien estructurado y claro, refactorizado y con pruebas de unidad, para que se pueda cambiar en el futuro.
3) otros parametros no funcionales, si por ejemplo se requiere que un determinado proceso tarde menos de x tiempo, se debe especificar en el caso de uso y se harán pruebas que lo validen.
4) robustez y control de errores. Debe haber un documento que especifique la forma de tratar los errores y el logging y debe hacerse de forma uniforme en toda la aplicación. De modo que si alguna vez nos encontramos un fallo en producción, el log nos diagnostique exactamente que ha fallado. Hay que poner cuidado en construir excepciones descriptivas, p.e. no un connection error sin mas, sino algo como:
"Connection failed using url=jdbc://192.168.3.1 patatan, user=dbuser, password=***", nested exception = tcp ip error destination host unreachable."