Una de las excusas más comunes de los programadores para no mejorar la calidad de su código es: solo las grandes empresas o los grandes proyectos pueden dedicar los recursos en pruebas y QA, para los equipos pequeños o el programador individual es un lujo tener pruebas. No estoy de acuerdo con esto, a continuación te explico el porqué:
¿Por qué a los equipos y empresas pequeñas les debes importar la calidad?.
Escribir programas y darles mantenimiento es un asunto económico, todo trata de dinero. Cada error le cuesta al equipo, ya sea en dinero o en horas de atención. Tu tiempo como programador es un recurso muy valioso, no lo debes desperdiciar en la búsqueda y corrección de errores triviales. Es obvio que los errores ocurrirán y deberás atenderlos aunque representen un gasto, eso no se cuestiona. Lo que debes de poner en duda es la importancia del error. Por ejemplo: un equipo de 3 personas que trabaja 8 horas a la semana tiene una bolsa de horas de solo 120 a la semana, gastar 16 horas a la semana por programador para resolver bugs de poca importancia y que pueden ser evitados, ¡es un desperdicio!.
Desde afectaciones a módulos de terceros (el típico: antes de tu liberación funcionaba X módulo), lo que el cliente crea que es un error (un requerimiento no definido puede ocasionar regresos); creación de bugs por el equipo de desarrollo al integrar cambios al control de versiones, resolver errores por coincidencia (el programador mueve algo en la aplicación y le dice al cliente: ahora sí, prueba), y la lista sigue… . Todos estos son síntomas en la degradación de la calidad de los aplicativos, que ahora cuestan horas que irán incrementando conforme pase el tiempo.
La falta de atención a la calidad es un asesino silencioso de la empresa.
Programar es una labor de administrar el dolor. Puedes elegir tener el dolor de tener que hacer las cosas bien o postergarlo. Mover el trabajo difícil a una segunda fase, o a más adelante en el tiempo. Estas cosas que dejes pendientes o a medias regresaran, siempre regresan. Esta es una práctica común en las empresas, se postergan las acciones correctas para entregar rápido. A este desfase de trabajo producido por trabajo entregado se le conoce como deuda técnica, tampoco está mal tener deuda técnica, siempre y cuando haya esfuerzo e intencionalidad del equipo para pagarla. Sin la debida atención, los años de descuido en los sistemas de la empresa puede llevarla a la quiebra. Esto se refleja en una productividad baja o nula del equipo de desarrollo. Los nuevos se dedican a pagar toda la deuda causada por gente que trabajo años atrás. Los síntomas de esta enfermedad se van a notar cuando sea tarde. Por eso el tratamiento preventivo es vital.
Cada centavo gastado en corregir errores en vez de prevenir, es dinero echado a la basura.
El soporte y el mantenimiento son cosas que ocurren en toda la vida del sistema, si al momento del diseño piensas en estos puedes ofrecer soluciones de calidad. Diseña para fallar, no solo para funcionar. La norma general es codificar, desplegar, entregar al cliente y después… ver como se prueba, bastante tarde. Cualquier posible error va a pasar muy adelante en el tiempo, y el coste va a ser alto en dinero o con prestigio delante de tu cliente. Error detectado en tiempo de codificación o en tiempo de pruebas es un ahorro automático. Debes tener mecanismos de detección y control de errores lo más pronto posible en la construcción de tus proyectos. En largo plazo se convierte en una ventaja competitiva.
El círculo virtuoso de la calidad.
Invertir esfuerzo del equipo en la calidad es una inversión con retorno a largo plazo. Los sistemas son construidos en capas lógicas y físicas. Cuando tiras los cables de tus sistemas no eres consciente que otros dentro de la empresa usaran ese cableado para sus aplicaciones. Ya sea reutilizando tus componentes o conectando tus servicios, es cuestión de tiempo para que alguien construya una capa sobre la tuya. Entre más confiables y seguros sean tus componentes, mayor será el número de programadores que se colgaran de ti. Hay mucha responsabilidad, también muchos beneficios. Los sistemas que mantienen un nivel de calidad alto, con bajo acoplamiento y alta reusabilidad pueden ser sujetos a ser escalables. Lo que abre la puerta a grandes oportunidades para la empresa.
Conclusiones.
Las grandes empresas no son grandes y luego piensan en la calidad. Al contrario, primero piensan en la calidad y luego se hacen grandes. La búsqueda por la mejoras de tu codificación y tu técnica de trabajo deben venir de ti, principalmente. Como programador eres el responsable por dejar los componentes mejor de como los encontraste, sin excepciones.
Autor imagen: Asrar Makrani
- NVL in SQL Server - 2023-11-01
- ¿Que es Cake Build? - 2023-02-22
- #How to fix error: MSB4019: The imported project «Microsoft.Data.Tools.Schema.SqlTasks.targets» was not found - 2023-02-20
