El mejor paper de Ingeniería de Software que leí en 20 años

Acompaño a @srlm en las redes sociales hace más de 15 años, se retiró como profesor de Ingeniería de Software de la UFPE hace algunos años, Master, PhD, creo que tiene algún post-Doc.. pero más que eso, tiene muy clara la visión de lo que vivimos y lo que se viene. Reposteo y comento algunos textos hace tiempo, tanto en el twitter como en el miniblog.

Hace unos días leí un paper que escribió junto a otros investigadores, y es lo mejor que he leído en mucho tiempo. En Ingeniería de Software, lo mejor que había leído hasta el momento era la frase de un gran autor de libros sobre el tema, "Software Engineering is bullshit". Realmente hay muchas técnicas, procesos, herramientas que ayudan a crear un mejor software, pero como estamos hablando de crear, realmente es un arte. Las técnicas, procesos y herramientas ayudan, pero los artistas son el componente más importante de la creación.

Luego de trabajar hace más de 15 años con software y específicamente hace 10 años en el área de Infraestructura y Operaciones, donde el principal objetivo es mantener al software funcionando, siempre, tengo algo de experiencia en que el software tenga problemas.. hemos utilizado herramientas, metodologías, procesos formales, hemos diseñado arquitecturas robustas, aplicado redundancia, homologado la infra y arquitectura específicas, pero siempre eso cubre una parte, la mano (la mente?) del creador, del artista, siempre ha sido una parte muy importante para que el software sea de calidad, y juntando la infra, el software, el soporte y buena documentación, podemos decir que tenemos sistemas de buena calidad.

Algo que aprendí en estos años, luego de saber que "Software Engineering is bullshit", es que podemos pasar a producción un software cuando el ingeniero (y software) es capaz de contestar a la siguiente pregunta: "How will I know if it breaks?". Eso vale mucho más que todas las pruebas que podamos hacer, aunque no digo que no haya que hacerlas. Aprendí esta y otras cosas en este interesante artículo acerca del tema. 

Pero, ahora, hubo importantes avances, este paper de Silvio Meira explica qué es realmente importante tener en cuenta al crear software: respetar el primer mandamiento. Dejo aquí el abstract: 

"Since the early days of computers and programs, the process and outcomes of software development has been a minefield plagued with problems and failures, as much as the complexity and complication of software and its development has increased by a thousandfold in half a century. Over the years, a number of theories, laws, best practices, manifestos and methodologies have emerged, with varied degrees of (un)success. Our experience as software engineers of complex and large-scale systems shows that those guidelines are bound to previously defined and often narrow scopes. Enough is enough. Nowadays, nearly every company is in the software and services business and everything is -or is managed by- software. It is about time, then, that the laws that govern our universe ought to be redefined. In this context, we discuss and present a set of universal laws that leads us to propose the first commandment of software engineering for all varieties of information systems."

Resumo básicamente lo que dice, aunque hay que ir a leer (pdf). No solo es excelente, sino que está muy bien escrito. Define reglas sencillas que deben ser seguidas:

SELFIE = Software Engineering Laws For Information [systems in] Everything

FU = every system, big and small, should have provisions that allow it to be FIXED and UPDATED either from within or outside the system proper.

CK = every system, big and small, should have provisions that allow it to acquire and make use of CONTEXTUAL KNOWLEDGE to decide whether it is functioning properly or not. 

IN = every system, big and small, should have provisions that allow it to be INDEPENDENT of its NETWORK as much as possible; in the absence of the surrounding network, systems should gracefully degrade to a level of usefulness that would resemble a fully independent, smaller, isolated system.

G = in GENERAL, for all kinds of systems, SECURITY and INTEGRITY concerns should supersede those of FUNCTIONALITY, which in turn ought to be balanced against USABILITY.

R = every system should have provisions that allow it to be REUSED in different contexts and by different systems.

E = every system should have provisions that allow it to be EXTENDED to accommodate new behaviors.

A = every system should have provisions that allow it to offer ANALYTICS to enable measuring and tracking of its use.

L = every system should have provisions that allow it to be LOOSELY COUPLED to reduce both the interdependencies across its modules/components as well as other systems that it possibly interacts with.

The combination of the above, REAL properties, with the aforementioned FUCKING ones leads us to REAL FUCKING LAW, which is the foundation for the development of REAL FUCKING systems.

Lo que deriva en el primer mandamiento: "Thou shall ONLY develop and deploy REAL FUCKING systems."

Es decir, todo REAL FUCKING system debe ser:

Reutilizable, Extensible, poder darte Métricas en el uso, Poco Acoplado con otros sistemas (lo más independiente posible). Además, debe poder ser arreglado o cambiado (en caliente), debe tener herramientas y métricas para poder saber cómo está funcionando (bien o no), debe ser lo más independiente respecto a herramientas y el contexto (plataformas/tecnologías), y los conceptos de Seguridad e Integridad deben ser más importantes que las Funcionalidades, y estas deben ser equilibradas con la Usabilidad.