EscucharSiempre me ha sorprendido como, a pesar de que existen muchas más diferencias que similitudes, la gente insiste en hacer analogías entre la ingeniería civil y la ingeniería de software. Las diferencias hacen las comparaciones injustas y engañosas.
La ingeniería civil es una actividad milenaria, bien entendida y regulada. La ingeniería de software, por su parte, está en su infancia, tiene poco más de medio siglo, y cada día hay más gente construyendo software sin planos y sin permisos, pero con una “buena idea”.
Mientras las obras civiles deben lidiar con los materiales y su desgaste natural, el software nunca se gasta, ni se deteriora y, sin embargo, requiere, proporcionalmente, mucho más mantenimiento que una obra civil.
Cuando una construcción colapsa, los ingenieros siempre diagnostican, a posteriori, con absoluta certeza la causa del colapso, pero cuando una pieza de software falla, la mayoría de las veces nadie sabe, ni puede determinar por qué falló. Sencillamente se vuelve a reiniciar.
Campos distintos. El modelo económico y de negocios asociado a las edificaciones es también totalmente diferente a los modelos asociados al software. Un edificio puede ser vendido una sola vez. El programa puede venderse cientos de millones de veces sin perder la propiedad de este.
Los inmuebles se deprecian lentamente, e incluso con buen mantenimiento y un poco de suerte se aprecian en el tiempo, mientras que el software se deprecia rápidamente y está constantemente expuesto a la obsolescencia tecnológica. Un software de hace 40 años no vale ni las tarjetas en las que está perforado.
La idea de un edificio que construya edificios no es algo que alguien quiera defender, mientras que software que produce software es más que una buena idea; es una realidad.
Parámetros distintos. La decisión de construir, comprar o alquilar una casa es un hecho bien estudiado y documentado. Las variables que deben ser medidas y comparadas son claras y obvias. La manera de plantear y tomar dicha decisión ha cambiado poco con el tiempo.
Pero la decisión de desarrollar, comprar o alquilar software es muy diferente hoy que hace 25 o 40 años. Los parámetros de la decisión han cambiado profundamente con el desarrollo de la industria, la globalización de la economía y la proliferación de conocimiento y pensamiento computacional.
Hace 40 años, casi todo el software había que construirlo, porque no había alternativas. Hace 25 años el mercado masivo de computadores personales hizo disponibles, para todos, softwares muy complicados de aplicaciones de oficina, como procesadores de palabras, hojas de cálculo, mensajería etc.
Hoy, nadie en su sano juicio desarrolla su propio software de oficinas, y cada vez hay menos gente que lo compra. La decisión obvia es alquilarlo en la nube, así siempre se tendrá la última versión, se reducen los requerimientos de hardware y se mitigan los riesgos de virus y otros softwares maliciosos.
Recuerdo haber escrito hace como 20 años quejándome del desperdicio que estábamos haciendo en el país al escribir miles de sistemas de contabilidad, los cuales básicamente hacen todos lo mismo.
Desde cero, es ilógico. Hoy, la decisión de desarrollar desde cero un sistema contable debe ser avalada por un psiquiatra.
A pesar de que a todos nos gusta pensar que somos únicos y especiales, y que nuestra organización es diferente al resto del mundo, es un error concluir que debemos desarrollar todos nuestros sistemas desde cero.
Los costos y los riesgos asociados al desarrollo de softwares, en organizaciones que no se dedican a este negocio, junto con la enorme disponibilidad de programas a escala global, obliga a analizar estas decisiones con mucho cuidado, y cada vez con más variables.
Comparar el costo de comprar un software con el de construirlo, es totalmente engañoso y casi siempre irresponsable, sobre todo tomando en cuenta el historial de (in) cumplimiento de costos y tiempos en el desarrollo.
El costo de no tener el software durante el período de desarrollo es obligación tomarlo en cuenta. Cada vez que se hace un programa nuevo, aumenta la carga y costo de mantenimiento. Ese costo no suele contemplarse al decidir construir.
No es extraño que una organización que construye todo lo que utiliza llegue a destinar el 90% de su esfuerzo informático al mantenimiento.
Inventar el agua tibia (por ejemplo con un sistema contable) obliga a desperdiciar el aprendizaje de miles y hasta millones de usuarios alrededor del mundo. Adicionalmente, el software desarrollado internamente está expuesto al mantenimiento: cada vez que lo modifican, el riesgo de romperlo aumenta. Ignorar los riesgos asociados al desarrollo es irresponsable, no hay otra palabra.
Falacias. Con frecuencia se esgrime el alegato de la dependencia de los proveedores que se genera al comprar o alquilar software. Este argumento es falaz por tres motivos.
Primero, eliminar la dependencia de todos los proveedores de software es imposible porque implicaría desarrollar todo el programa, no solo las aplicaciones –como las de oficina– sino también las herramientas de desarrollo, bases de datos, sistemas operativos y un largo etc.
Segundo, eliminar la dependencia de los proveedores de software aplicativo implica tener el código fuente (el lenguaje que utilizamos los humanos para escribir el programa) y esto puede traer implícito un riesgo de control interno, pues para violar la seguridad o integridad de un sistema o sus datos es muy útil el código fuente.
Tercero, al eliminar la dependencia del proveedor de software (escribiendo u obteniendo el código fuente) se crea automáticamente dependencia de uno o varios funcionarios.
Riesgos. En la industria del software, la rigurosidad del proceso de desarrollo, el control estricto sobre el código fuente, el control de versiones, la automatización de pruebas y otras medidas costosas mitigan el riesgo que las organizaciones usuarias suelen asumir de manera casi inconsciente.
Empresas en la industria del software que asuman los riesgos que suelen asumir las organizaciones usuarias en el desarrollo del programa desaparecerían muy rápido.
Hace 20 años, si un país, grande o pequeño, quería un sistema nacional de pagos electrónicos, tenía que construirlo, no había otra. Hoy la decisión sería muy diferente.
Hoy, un país atrasado que no tuviera sistemas de expediente médico, expediente educativo, factura electrónica, contabilidad municipal, pago de transporte público o recaudación de impuestos deberá explicar a la ciudadanía (y al psiquiatra) por qué desarrollar cualesquiera de esos sistemas, si ya existen muchas veces alrededor del planeta.
Inventar el agua tibia es una decisión que no debe tomarse a la ligera, y debe siempre justificarse claramente a los dueños de la organización, ya que las repercusiones de una mala decisión suelen sentirse durante décadas.
El autor es ingeniero, presidente del Club de Tecnología y organizador del TEDxPuraVida.
