|
In this issue: the project idiot; AI and SE: From Probable to Provable; successful applications of AI to the teaching of software engineering; recent and forthcoming talks; forthcoming book.
Every project needs an idiot
In a project presentation meeting long ago, the participants heard enthusiastic presentations of a new, sophisticated computer architecture with marvelous features. When the time came for questions a colleague of mine, a well-known computer scientist who was being asked to serve as a consultant to the project, raised his hand and broke the silence. "How does one do a load and a store?"
He was playing a role that every software project needs to fill: the project idiot role. Agile development, specifically Scrum (Agile! The Good, the Hype and the Ugly, Springer, 2014), famously defines three roles -- three only -- for every project: self-organizing team, product owner, Scrum Master. They forgot the idiot.
The project idiot is the one who is not afraid to ask the simple, embarrassing questions. We could also call him the project child, in homage to the character in Andersen's The Emperor New Clothes who articulates what no one else has the guts to ask, but “idiot” has a certain mnemonic knack to it.
The role of the idiot in software projects — one that I often try to play, with my special qualifications — is often to take the viewpoint of the unsuspecting customer or beginning end-user, which developers, ensconced in the design and familiar with all the subtleties of using the system, can easily forget. By asking “how does one do this?” (where “this” can be trivial to the experts but intimidating to novices), “why is it so complicated?”, “does anyone actually need this?”, “is it the way people will reason?”, “how will they discover that they can do this?”, and so on, the project idiot can bring everyone down to earth and prevent the project from producing a result that is elegant inside and unusable outside.
Successful applications of AI to teaching software engineering
I am involved in a new workshop (Sept. 27-30, in Villebrumier near Toulouse): FISEE 2026. FISEE stands from Frontiers In Software Engineering Education and is actually the third in a series; the previous ones were FISEE 2019 and FISEE 2023. The theme this time is “Artificial Intelligence, Software Engineering and Teaching: Recipes for Success”. The double focus is on:
- Successful experiences.
- Teaching of all of software engineering (rather than just programming).
The program chairs are Armando Cox (Berkeley), Jean-Michel Bruel and Sophie Ebersold (Toulouse) and Manuel Oriol (Zurich). The Web page (which still needs a bit of a cleanup) is at https://www.laser-foundation.org/fisee/2026_/ (note the final underscore).
If you are interested in how to use AI effectively in SE, please consider contributing.
New paper: AI for SE, from probable to provable
I have mentioned this paper before in its pre-publication (arXiv) form. It has now (as of yesterday) been published in Communications of the ACM as a “viewpoint”. The title is Artificial Intelligence for Software Engineering: From Probable to Provable. Here is the link: https://cacm.acm.org/opinion/artificial-intelligence-for-software-engineering-from-probable-to-provable (ACM publications are now open-access).
Here is a summary of the argument:
- It is fine to want to "marry AI with software engineering", but the former is creative and approximate, while the latter is strict and error-intolerant (see the article’s illustration).
- It is fine to say that "with AI we no longer need programmers", but that has been said many times before with the introduction of new technologies, starting with COBOL and continuing with 4GLs, component-based development, model-based architecture, low-code/no-code etc.. These advances elevated the level of abstraction but did not remove the need for programmers. So the real question is: are we facing a similar situation, or are things truly different this time around?
- It is fine to say "with AI we no longer need to code", but coding typically represents at most 15% to 20% of the effort of a serious software project. What about the rest?
- It is fine to say “from now on we just express what we want to do and AI will do it,” but “expressing what we want to do” is requirements engineering, one of the hardest parts of software development. (See my book on the topic: Handbook of Requirements and Business Engineering, Springer, https://se.ethz.ch/requirements.)
- It is fine to say “we no longer write the code, AI generates it”, but what about its correctness? AI generates beautiful things but hallucinates from time to time. If each module has an excellent probability of being correct, 99.9%, 1000 modules (assuming independence) have a little more than a one-third chance (37%) of being correct, and for 5000 modules the probability drops to less than 1%. Hence the essential role of verification, and particularly of formal methods.
- It is fine to say that “programmers also make mistakes”, but the context changes considerably. The bugs produced by programmers take roughly known forms, and we know roughly how to detect and correct them. The hallucinations of AI tools are much less well understood and their forms are difficult to grasp. In the extreme, an error comes from an erroneous value (weight/parameter) in a matrix of millions of elements! Terra incognita.
Among the conclusions: AI in software engineering is here to stay; it has already profoundly transformed the field, but the success of the marriage requires a new impetus in disciplines such as requirements engineering and software verification.
The link again: https://cacm.acm.org/opinion/artificial-intelligence-for-software-engineering-from-probable-to-provable/.
Recent and forthcoming talks
I gave keynotes recently, on topics close to the article cited above, at the Swiss Testing Day in Zurich (https://swisstestingday.ch/) and the ICEIS conference in Alicante, Spain (https://iceis.scitevents.org/?y=2026). I also gave an ACM Webinar, which was watched by a large audience, over 1300 effective participants (announcement here), with a recording now on YouTube.
I do not like to give the same talk (actually, never quite the same, but variations) forever, so I am changing topics for the forthcoming scheduled appearances. At SPLASH/OOPSLA in early October I am slated to give a keynote at a workshop on language standardization and specification and also to be on the panel for the 40th anniversary of OOPSLA. In the workshop keynote I will talk about the long-running experience we have had through the design, evolution, specification and standardization of Eiffel.
Before that I will give a keynote in September at a conference I did not know, which seems really interesting: SYNASC 2026 in Timisoara, Romania, which includes a symposium on formal methods. I will talk about the development and future prospects of the AutoProof verification development for Eiffel.
Even before, I am stepping out of my comfort zone by going to different topics: on June 28, a talk on the great glassmakers (Art Nouveau, Art Déco) of the French Belle Époque: Gallé, Daum, Schneider, Delatte etc.; and at the end of June a talk at the International Pascal Congress in Salamanca, Spain, June 22-26. This is a Delphi gathering; no, I have not gone over to Object Pascal, but they invited me to talk about their inspiration, Niklaus Wirth, probably as a result that the very personal obituary that I wrote (blog version and journal version). I will also present a tutorial on Design by Contract there.
Forthcoming book: understanding AI
Another way of getting out of my comfort zone: I am putting the finishing touches to a book on AI, entitled “Understanding Artificial Intelligence”, subtitled “The Triumph of Experience”. I give it another 3 weeks or so (that prediction is definitely not "the triumph of experience" but one cannot be a programmer without some dose of unbridled optimism).
I got into this for two main reasons: I became fed up with all the pseudo-experts who pontificate about AI — whether for or against — without understanding, let alone explaining what Modern-AI is about. And by asking around smart technical (but non-computer-scientist) people, I was surprised to see how many understand how little of the technology. Unable, for example, a simple question such as “take a neuron in a neural network: what kind of function does it compute?”. It is great to be using ChatGPT, but better to have some idea of what lies inside.
I may be a pseudo-expert too but I think I can explain the basics sell and ensure technical correctness.
The book is introductory; it includes both general discussions and technical presentations of the main principles and constituents of today's systems. It assumes a very basic mathematical knowledge (high-school-level at most) and explains all the math needed, in simple terms.
It will be an e-book. There will be a discount for the readers of this newsletter (discount code NEWSLTR, I will provide it again). It will be sold like software, with 1-year free updates. Obviously I will announce the publication in this newsletter as soon as it happens.
Cover photo: Outside shop display, Spain.
|