The coming software apocalypse

In a 2017 article from the Atlantic, « a small group of programmers wants to change how we code—before catastrophe strikes » !

As a reader, I knew about the Business Analyst difficulties to make business needs answered by software engineers, but I am stunned by what I read in this article about the reality of software programming …

From a long history of software bugs like in New York Stock Exchange and the Toyota « sticking pedal » issue, programmers are (at last ?!) discovering the major importance of writing down specifications before building a solution !

Ravi Shivappa, the VP of group software engineering at Meggitt PLC writes : « traditional projects begin with a massive requirements document in English, which specifies everything the software should do. (A requirement might be something like, “When the pressure in this section rises above a threshold, open the safety valve, unless the manual-override switch is turned on.”) The problem with describing the requirements this way is that when you implement them in code, you have to painstakingly check that each one is satisHed. And when the customer changes the requirements, the code has to be changed, too, and tested extensively to make sure that nothing else was broken in the process. »

« The problem is what to code. Because most of the requirements are kind of natural language, ambiguous, and a requirement is never extremely precise, it’s often understood di_erently by the guy who’s supposed to code. » says Eric Bantégnie, founder of Esterel Technologies, a French company that makes tools for building safety-critical software.

He is pioneer (!?) of the industrial use of « model-based design, in which you no longer write code directly. Instead, you create a kind of Jowchart that describes the rules your program should follow (the “model”), and the computer generates code for you based on those rules.«  by « representing this rule with a small diagram, as though drawing the logic out on a whiteboard, made of boxes that represent di_erent states—like “door open,” “moving,” and “door closed”—and lines that define how you can get from one state to the other. The diagrams make the system’s rules obvious. » . 

Gerard Berry, a computer scientist at INRIA proposes : « Instead of writing normal programming code, you’ create a model of the system’s behavior » 

Leslie Lamport, a Turing Award–winning computer scientist notes « Architects draw detailed plans before a brick is laid or a nail is hammered,” he wrote in an article. “But few programmers write even a rough sketch of what their programs will do before they start coding. »

Chris Newcombe, principal engineer at Amazon developed « TLA+, which stands for “Temporal Logic of Actions,” is similar in spirit to model-based design: It’s a language for writing down the requirements—TLA+ calls them “specifications”—of computer programs. … Engineers at the European Space Agency used it to rewrite, with 10 times less code, the operating system of a probe that was the Hrst to ever land softly on a comet. Intel uses it regularly to verify its chips. »

It seems like programmers are discovering the Value approach :

  • « what for » is a the software ?
  • « what is enough » to do it ?
  • « work with stakeholders« 

and discover ‘system modeling‘ tools to formalize the answers …

I am quite sure synergies can be built with Business Analysis and other Value(s) methods !

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *

Ce site utilise Akismet pour réduire les indésirables. En savoir plus sur comment les données de vos commentaires sont utilisées.