Hoy en día cuando te enfrentas al desarrollo de algún proyecto software, por mucho que hayas definido una buena arquitectura de la aplicación y por mucho que tengas industrializado el desarrollo, si alguien rasca, va a encontrar chapuzas.
Salvo que te encuentres en un proyecto en el que la calidad es crítica, por ejemplo en aplicaciones sanitarias, y consiguientemente el coste va aparejado, lo normal es que los clientes no estén dispuestos a pagar la perfección.
Como buenos profesionales que queremos ser, esto es muchas veces duro de asimilar, porque quieres hacer un trabajo redondo, pero tienes el tiempo y el dinero para hacer un proyecto redondeado, que no redondo.
En la carrera tuve un profesor de economía que nos dijo algo palmario. Si tienes un negocio en el que te roban un millón (de pesetas) al año y poner un sistema para que no te roben te cuesta tres millones (de pesetas), prefieres que te roben.
Esto es así, pero lo que no debemos es dejar que se convierta en un coladero, en un planteamiento de como es una chapuza, para que me voy a esforzar. Para ello lo ideal es que esté definido lo mejor posible que es lo que espera el cliente obtener, es decir los requisitos funcionales y técnicos.
La filosofía que intento inculcar a los compañeros es la de: «Si rascan encontrarán, pero por lo menos que se tengan que dejar las uñas rascando» que va un poco en la línea de Pruebas que no podemos fallar