No hay suficientes programadores profesionales para todo el software que necesita nuestra sociedad. Aquí propongo una serie de soluciones alternativas.

1. ¿Quién va a desarrollar las Apps del
futuro?
Jordi Cabot
@JordiCabot / @ingdesoftware – jordicabot.com / ingenieriadesoftware.es

2. About

3. SOM Research Lab
Software runs the world. Models run the software

4. Nuestra misión
Interested in the broad
area of systems and
software engineering,
especially promoting the
rigorous use of software
models and engineering
principles in all software
engineering tasks.
Flickr/clement127

6. Disclaimer

7. Cualquier parecido con la (futura)
realidad es pura coincidencia

8. “As a writer, my job is to change your
perspective and make you think
outside the box.” - Mary Sage Nguyen

10. El problema (o bendición)

12. De hecho, no solo toda empresa, sino toda la Sociedad
se basa en software, y aún más, software libre

13. + CPS
+ IoT
+ Blockchain
+ Quantum
…

14. Example: Chatbots are complex systems
Conversation
Logic
Text Processing
External Services
Messaging
Platforms
Deployment
Evolution
Maintenance
Tests
Xatkit.com

15. Más programadores NO es la solución

16. Shallow work:
non-cognitively demanding,
logistic style task, often
performed while distracted
¿Programación = shallow work?
Escribir código es la manera
menos eficiente de produir SW

17. 0
10
20
30
40
50
60
Programmers (in M)
Estimated number of programmers (EEUU)
Potential amateur programmers self-declared amateur programmers PROs

18. SW
Eng
Developer: Creates
working software
Programmer: Writes code

19. 5 soluciones (a combinar)

20. Solución 1: Que desarrollen los
analistas y diseñadores

21. Ingeniería de Software Dirigida
por Modelos (IDM/MDE)

23. • Grady Booch – history of softwre engineering
The entire history of software engineering is that of
the rise in levels of abstraction
- Grady Booch
OBJETIVO: Escribir cada
vez menos código

24. Todo dominio suficientemente avanzado tiende al
modelado (ej. Machine Learning)

25. Model
Rapid prototyping
Static analysis
Code generation
Automated testing
Refactoring/
Transformation
Documentation
[Illustration by Bernhard Rumpe]
IDM = Modelos como parte central de la
Ingeniería del Software

26. Modelo: simplificación útil de la realidad
26
Ciudad de Nantes = “system” a
modelar
Un mapa es de hecho un modelo
del sistema
La leyenda del mapa es la
gramática / metamodelo
Existen diferentes tipos mapas:
transporte, alcantarillado,…
que dan “vistas” diferentes de
la ciudad

27. Muy parecido al mundo de la
programación
MDE Grammarware
MOF
(metametamodel)
UML
(metamodel)
ABank.uml
EBNF.g
Java.g
MyProgram.java

28. Original
model
1st
refinement
nth
refinement
Model-to-model
Transformation
Model-to-text
Transformation
...
Requirements
Use Case
Class Diagram
Java Project

29. La equación IDM:
Models +
Transformations =
Software

30. Podemos añadir tanta semántica como
queramos en un generador de código
Regla de Pareto aplicada a la generación de código: el 80% del código es repetitivo

31. Algo que todos hacen

32. Beneficios MDE
(bien hecho)
+productividad +calidad +Mantenimiento ….
2X – 8X 1.2X – 4X 80%

33. Y sí, se puede ser ágil y modelar

34. To model, or not to model, this is the WRONG
question
- Shakespeare
La buena pregunta:
qué modelos, cuantos,

35. Me prohibieron utilizar mis
500+ slides de “introducción a
la IDM”  -> mdse-book.com

36. Low-code

37. Adopción MDE

38. Low-code application platforms accelerate app
delivery by dramatically reducing the amount of
hand-coding required – Forrester Report

39. Low-code is a “style” of MDD
• Focused on specific types of applications
• Where the language/s are typically fixed and closed
It’s a marketing success
• Huge amounts of VC money for low-code tools
• All tools are rebranding themselves as low-code tools!

41. Low-code is trending because
• Clearer message: Everybody understands
that low-code means “less coding”. MDD is
more confusing
• Sounds familiar, and less scary, as the
marketing msg is still focus on the code.
• Simpler pipeline, no transformation chains,
one-shot modeling.

42. Solución 2: Que desarrollen los
usuarios (citizen developers)

43. Todo usuario
esconde un
programador en
su interior

44. Citizen developers = End-User programming 2.0
¿Ahora
sí?
Demanda
Plataformas
no-code
Cognification

45. “the goal of the project is to
make the promise of
open data a reality by
giving non-technical
users tools they can use
to find and compose the
information they need”

46. No-code

47. In a no-code approach users
• “Develop” reusing predefined templates and services
• It’s more of configuration / plugging approach to
development
Diff with low-code
• Here we asume zero coding
• This limits creativity but still covers a good range of apps

49. Solución 3: Intentemos que la
comunidad nos ayude

50. Code
Community

52. Tenemos que ser un poco
de «letras»

53. Successful
OSS tool
Governing
Optimizing
Onboarding

55. Ponerlo en pràctica: Software Analysis

56. No se trata
de hacer
análisis
estático del
código

57. Optimizemos la “poca”
ayuda que tendremos

59. Build the right
graph
for yourpurpose
On the analysis of non-coding roles in open source development
An empirical study of NPM package projects
•J.L. Cánovas Izquierdo & Jordi Cabot. Empirical Software
Engineering volume 27, Article number: 18 (2022)

60. Bus Factor
“Number of key developers who would need to be
incapacitated (hit by a bus), to send the project into
disarray that it would not be able to proceed”

61. Attracting contributors
(and keeping them)

62. Facilitateon boarding: Importance of first
impressions

63. OSS = matching market
(mercados donde el dinero
no es el factor principal)

64. © Apple Records
Governing:
Power to the people

66. La governanza de
los proyectos tiene
que ser
transparente

67. Benevolent
Dictator for Life<-
Why???

68. Los proyectos
OSS deberían
ser más
democráticos
(y no, forking
no es una
buena opción)

69. ThemanynamesofDemocracy

70. ******

71. Project myProject {
Roles: Committers
Deadlines:
myDeadline : 7 days
Rules:
myMajorityRule :
Majority {
applied to Task
when TaskReview
people Committers
range Present
minVotes 3
deadline myDeadline
}
}
All the proposals for new development tasks will be
accepted or rejected in 7 days by the committers of the
project.
Verbalization

72. Solución 4: Dejar que una IA haga
el trabajo

73. Cognificación

74. Cognification:
The application of knowledge
to boost the performance
and impact of a process

75. Durante la revolución
industrial todo se
electrificó.
En la próxima todo se
“cognificará” con acceso
barato una AI especializada

77. OutSystems.ai

78. 85
Artificial Intelligence
Machine
Learning
Natural
Language
Processing
Domain Modeling
assist
Natural Language Processing (NLP) for model
autocompletion

79. Funcionamos mejor juntos

80. El mejor jugador de ajedrez
del mundo no es ni un
humano ni una máquina

81. Kai-Fu Lee

82. La ACM ha propuesto 7
principios para la
transparencia y
responsabilidad de los
algoritmos
RESPONSABILIDAD
Las instituciones son responsables de las decisiones tomadas por sus algoritmos,
aunque no sean capaces de explicar el cómo se ha llegado a esas decisiones

83. Solución 5: Que nadie haga (casi)
nada...

85. No-work
Hay suficiente información disponible
•Para saber qué hacer y como hacerlo
•Sin que, por ejemplo, haya que formalizer los
requisitos.
•Mezcla de información de la empresa y conocimiento
general.
Ejemplo: chatbot para tienda e-Commerce
•Si tengo los datos de la tienda puedo deducir qué
conversaciones sobre esos datos hay que tener
disponibles.
•Esto permite tener un chatbot automático sin que el
propietario tenga que hacer nada. Ni low-code, ni no-
code ni nada.

86. Conclusión

87. El “10x
programmer”
existe
… pero no es
un programador
Cualquiera de
vosotros puede serlo
con las herramientas
adecuadas

90. ¿seguimos
hablando?:
jordi.cabot@
icrea.cat
@JordiCabot
@ingdesoftware