Intentional Software

Trusting Relationships

In their 2005 book John Seely Brown and John Hagel III advise that The Only Sustainable Edge for a business is to accelerate and leverage distinctive capabilities and knowledge.They advise each business to work closely with others in networks of companies that have diverse, complementary capabilities, and to build long-term reciprocal, trust-based relationships through shared meaning.

Brown and Hagel’s book is the first place we have seen articulated so many of the objectives our company is working to achieve.

Long-term reciprocal, trust-based relationships are the fundamental common denominator.

And Building shared meaning is, in my judgment, the single most critical specific action that Brown and Hagel prescribe for building those relationships. Long-term reciprocal, trust-based relationships simply cannot survive unless all participants understand each term in precisely the same way. During my career as a business attorney, lack of shared meaning caused by far the most disastrous disputes and uncertainties my clients ever faced.

In fact, our Intentional Software™implements much of Brown and Hagel’s advice by representing precise, unambiguous, shared meanings that are recorded in one internally-consistent data structure from which applications are generated, modified, maintained and regenerated by computer. This data constitutes an understandable “IP Bank” repository of learning and knowledge for reuse throughout the life of an enterprise.

Implementing reciprocal, positive forward looking incentives is the primary action Brown and Hagel prescribe for building trust quickly in any network of enterprises. They explain why the opportunity to build mutual capabilities that result in more aggregate value for all participants is a very powerful incentive to help build trust in the near term. Each participant thus has an incentive to contribute its distinctive, specialized yet complementary capabilities and knowledge because it can reasonably expect to accelerate and leverage its own capability building, learning and innovation through reciprocal contributions by others in the network. These positive incentives are contrasted against negative incentives that often cause disputes in typical partnerships that simply agree to divide a fixed set of resources among the partners.

Clearly specifying performance metrics for each participant is also prescribed by Brown and Hagel to reduce misunderstandings and mistrust and to define reciprocal expectations. Each participant thus retains control over its own actions and ability to perform, rather than being constrained to perform specified activities. Critical uncertainties are identified, and plans are made to deal with them. Tight performance feedback loops, and event notification and rapid exception resolution procedures are employed to help refine performances and to serve as safety nets. Steps are also taken to minimize a participant’s feeling that it is locked into a relationship with no fallbacks.

When we formed our company in 2002, we defined our fundamental objectives in words very similar to Brown and Hagel’s. And since then we have in fact been working “to accelerate and leverage distinctive capabilities and knowledge by working closely with others in networks of companies that have diverse, complementary capabilities, and by building long-term reciprocal, trust-based relationships through shared meaning”. No doubt that is why Brown and Hagel’s 2005 book fascinates us so much.

Fundamentally we work hard to reduce uncertainties and to build foundations for long-term relationships. Our litmus tests are to verify that all participants communicate their own intentions openly and clearly, and to structure each business relationship affirmatively to implement the intentions of all participants (not just our own). We seek to align the interests and incentives of all participants equitably in form and substance, measured by objective standards.

To the same ends we are keeping our company as innovative, efficient, persistent, opportunistic and evolutionary as possible. We love bright, enthusiastic, imaginative, risk taking, fun loving, trusted individuals who enjoy working together.

Our company’s business is accelerating innovation for business. Intentional Software is our means.

MIT Technology Review Article

We are delighted to be the cover feature of the current issue of MIT Technology Review. It was fun for me to spend time with Scott Rosenberg, and to show him what we are doing here at Intentional Software.

The article discusses our ambitious goals. We are working on a very tough and very technical problem and we understand the skepticism. We have early users, they are very supportive of our goals and their feedback is vital during this critical stage of development.

Because the content is so technical, readers might have some additional questions on the details. We have addressed some of these topics such as Degrees of Freedom which addresses the concept of the “Law of Leaky Abstractions”, or what is the role of the Generator, or on Hungarian Notation.

Thank you again to Scott for taking the time to delve into Intentional Software, and congratulations for the publication of your new book, “Dreaming in Code”!

And, lastly, thanks to all of you who are following us on this journey. We will continue to keep you informed of our progress.

By the way, I’m posting this from Star City in Russia where my space mission training is continuing for the April launch.

Charles Simonyi

ps. We are always looking for talented programmers. Please send us your resume if you want to join a great group and have an impact on the most exciting area in software.

Rosetta Code

Not long ago Charles gave a talk at the Society of Computer-Archeologists in Denmark entitled "The Rosetta Code". The title refers to the Rosetta Stone which was key to the deciphering of hieroglyphs as it contains the same text in two languages and three different alphabets. You can still see it in The British Museum.

Software history buffs will appreciate the talk as it draws upon examples of how the Algol compiler designed by Peter Naur was implemented. (Charles first job after he left Hungary was to maintain this code...). Peter Naur had been the editor of the very influential Algol report from 1960 which ended up shaping the design of most programming languages in use today. Naur recently received the Turing Award for these achievements.

The analogy to the Rosetta Stone refers to the three levels of the compiler: the implementation, the comments and the overall design.

• The implementation is in machine code.
• The comments use a high level langauge to express the design intentions. The "comment language" looks very much like Algol itself, although often extended in various ways. Today we take the high level language for granted and we seek other, more powerful means to express our intentions. Also note that already in those days they introduced notations that we today would consider revolutionary in a programming language like ≡ ¬ ≠ and ₁₀. It is also impressive to see how efficient the machine code is; it is often less than the actual pseudo Algol code it is implementing!
• The design intention itself is a piece of handwritten paper.

Here is the presentation.

Wysiwyg

The introduction of Wysiwyg editors is a useful historical metaphor to what can be done to deal with complexity when expression and manipulation of non-trivial data is required. Before Wysiwyg editors became popular, document editors were called text-editors, since they represented only the text contents of documents. As an intermediate stage of development, special character combinations (or “control codes”) were used to encode and represent what the formatting should be, for example ^i might turn on italics, and so on. This style of encoding is still in use in HTML and its successors where <i>italic</i> are the control codes to italicize. Today, a user of a word-processor does not have to make a distinction between the italic character i and its representation. A word processor allows a user to express their intention to italicize certain text elements.

A more telling example is justification, for example right margins. Pre-wysiwyg, when a user invoked the Justify command, the word processor went through the document and added extra spaces to create the justification. When the user added or removed some text, the spaces often ended up in the wrong place and it was a manual process to remove them all and again justify the text. Running the justify command was a big decision you rarely invoked until you were pretty convinced it was the final version of the text you were justifying. Of course, computer supported justification was still much better compared to what was before, namely manual typesetting, where justification was even more manual.

Today, we express the intentions of italicizing and to keep a text justified in a word processor, not by special control codes or running a command, but the editor keeps and maintains it justified on the screen for editing and also for printing by an internal representation. This is an example where intentional information is not only more compact and effective, but also improves tremendously the usefulness during editing and maintenance.

The word processing software effectively separates the look and feel of the document (“What you see”) from the underlying representation which is used during editing and printing (“what you get”). It thereby makes it possible for the user to create and edit much more complex and effective documents without mastering the control codes or commands.

We see that in Wysiwyg editors the user express intentions which are projected as the text is imaged either on the screen or on the printer. Intentional Software applies a similar Wysiwyg technique to the creation and maintenance of software by separating the representation from the looks and the editing interface. In the realm of software creation we can observe a similar trend where we used to encode only the most critical information – namely the executable algorithm – but we more and more find it useful to encode information about the problem and the process itself – the intentional information, for example as meta data in XML configuration files.

But there is an even closer connection between the use of Wysiwyg and the use of Intentional Software when we investigate the process of software creation.

What was the core Wysiwig idea? Superficially it was the emulation and improvement over the typewriter. But this is clearly not the whole story – for example on a typewriter words do not automatically flow from one line to the next. How did people make words flow on a typewriter after a document had been changed – whether it was a contract, a movie script, or a doctoral thesis? Why, they gave it to a typist who retyped the text. I remember the time when the first thing a graduate student preparing to write a thesis would do was to hire a typist. You may not remember, but before Wysiwyg there were many professional typists. They were employed not so much because people could not type- that was just part of it, but because people could not re-type. They not only originated documents from notes or dictation, but they spent most of their time re-typing already typed drafts which were marked up with corrections or changes.

This was terribly error prone, because when a page was re-typed to fix a sentence or a number, errors could be introduced in other places. So when someone wanted to make a few changes in a contract, there was a lot of discussion in how to make sure that the rest was still OK, in effect the proofreading had to start from scratch. We tend to forget how tricky it was at that time to decide whether an important contract should be retyped after a small change: because the process of retyping could easily cause some mistakes in an unrelated part. If the contract was retyped for a clean copy, the whole page or more would have to be re-checked by all parties. This was completely eliminated by Wysiwyg. We still need to originate documents, but we never have to retype them and suffer the risk of those errors. Of course this is exactly how software creation is working today. When a small change is contemplated, its possible effects on the whole system have to be taken into account.

So in effect, the Wysiwig word flow feature was the emulation of the typist, not an emulation of the typewriter. In other words, Wysiwyg was not just an improvement on the typewriter, Wysiwyg was an improvement on the document creation process. 

There is a very strong parallel with Intentional Software. The parallel to the author of the contract, the script, or the thesis, in other words to the content creator is the domain expert. The parallel to the typist is the programmer (or more, accurately one of the roles of the programmer). Once the first implementation exists, the programmers’ job becomes very much like the typists’ job used to be: to do the repetitive work of accommodating the changes, small and large, and to propagate the consequences of the changes in the software code, in effect doing the word flow.

Programmers are terrible at this. Remember how the frequent retyping before Wysiwyg caused many mistakes. But today software is still created this way. When a change is introduced, other bugs creep in. Many seemingly unrelated parts of the software has to be re-checked. Interaction between different parts of the software is becoming increasingly hard to understand and deal with as the complexity and size of our software grows.

The analogy suggests more parallels. Corresponding to the typewriter we now have conventional programming technologies, tools, processes and platforms. Note how incremental improvements to the typewriter, such as the “correcting white-out tape” did not help with the underlying problem of constant retyping. Similarly, the incremental improvements to the programming techniques will not help with the need for re-doing the “change propagation analysis” or “coding pattern expression” every time a change is made to the code. We also see that a job role, such as typist or programmer, includes many different activities some requiring considerable skills, while others can be readily automated. It is pointless to try to “automate” a programmer, but it can be very valuable to organize the programmers’ job so that some of these simple repetitive activities are done by the machine, freeing up the programmer to do more of the knowledge-intensive tasks. That is what generative programming can do, by recording, in effect, the process by which the resulting software can be related to the domain experts’ intentions, so that this process can be mechanically re-played, just as the retyping and reformatting of the documents of yesteryear is now done automatically by the Wysiwyg editors.

Wysiwyg transformed the document creation process by giving content creators direct control of the process. Similarly, Intentional Software intends to transform the software creation process by giving the business domain experts – the content creators - direct control of the process. Wysiwyg empowered millions of more users to author great looking documents – it is time to do the same for software users.

Learn more about Intentional

This fall you will have two opportunities to learn more about Intentional. We will be presenting at two major conferences, JAOO and OOPSLA. At both conferences we will give an update on our technology and also do a sneak preview of the software.

First at JAOO, which is in Aarhus, Denmark, October 1-6, we will be presenting Intentional Software in the “Domain Specific Languages, and Beyond” track. This track is bringing together some interesting presenters to highlight practices around DSLs. Just based on the session descriptions Intentional is probably the “...and Beyond” part ;-).

Then at OOPSLA, which is in Portland, OR, USA, October 22-26, we are presenting a paper on Intentional Software in the Onwards! track. We are honored to be included in this track which, to quote the OOPSLA description, “…is the place to reveal the revolutionary, air the provocative, and expose the subversive.

Both JAOO and OOPSLA have a strong reputation on bringing together thought leaders in the software space. These conferences are often the first to highlight new and emerging technologies. These conferences are typically where you will hear about new developments, before they show up in trade magazines. We are very honored to be invited to both of these world class conferences and look forward to meeting many new and old colleagues, perhaps including you.

A Process With the Right Degrees of Freedom - the Lagom Process?

We have discussed a few times earlier the need to use the right abstractions, or the right degrees of freedom, to solve a problem. The best solution is something that exactly fits the problem domain, being it the right size screwdriver, a software platform or a programming language. Often times our languages, tools and platforms have too many - or even worse too few - degrees of freedom and we have to put in extra work to compensate for the superfluous or missing degrees. To quote from our earlier posts:

So to generalize the “harmfulness” theory, we need to refer to the degrees of freedom in the problem statement, in the domain intention. A programming feature is harmful in proportion that it has more degrees of freedom than in the domain intention that it is used to solve. By degrees of freedom we mean the potential parametrizations (arguments, properties, attributes, or parameters) for the abstraction and the gamut of their values. This latter is determined by the parameter type: the range of possible parameter values can be small for enumerated types, or very large, for example the “parameter” is a statement list as in a loop. Harmfulness is related to excess degrees of freedoms: more parameters than necessary, or larger parameter types than necessary for the purposes of the problem intention.

We can expand this idea to also apply to the actual process being used. If a process adds more steps, tasks, deliverables – in summary more work – that is required, we think of the process as getting in the way and not helping. The process is causing extra work, it causes errors, and it adds complexity. In fact a lot of the processes that are popularized today is actually compensating for missing degrees of freedom in other areas. We need to work around the lack of power by copying information, reworking and repeating. For example, because we have no good way to transfer the domain intentions between the domain expert and programmer, the industry has come up with many ways to compensate for this problem in the process. Examples include modeling, customers on site, prototyping, iterative development, storyboarding, meetings, specs, use cases and user stories to name just a few.

What are the right degrees of freedom for an ideal process? It could be something that helps make the right tradeoff of change and progress. In other words, when a change is needed, we not only allow the change, but also implement the change in a way that ensures progress. Here we use “a change” fairly broadly. From the dictionary:

A transformation or transition from one state, condition, or phase to another

A change early in a project could be from an idea of a new product to something tangible, for example a prototype. A change later in a project could be to refine the functionality of a user interface. The tradeoff between change and progress is important because we need to organize the work so that every change also ensures progress. We wrote earlier about a process idea from Christopher Alexander that is now surfacing in a different field, namely architecture. Alexander suggests a new type of process he refers to as “making” where the customer, architect and builder are collaborating during the entire process and refines the degrees of freedom continuously to make something that exactly fit the customer’s needs.

Jimmy Nilsson has some similar ideas. He argues that Extreme Programming is sometimes perceived as too rigid or too extreme. Rather, he suggests a “Lagom Process”. (Lagom is a Swedish word that means something like “just right for this situation”. He describes the process as “It's probably influenced by Agile, but it's built up of the pieces that together form a mix that is lagom for the team and project at hand. That's it.”

On a similar topic, Jeremy and I met with Ivar Jacobson last week. Ivar described how he is now rethinking the whole Unified Process approach into something completely different. It is clear that over the last few years it has been a challenge to separate the domains, or concerns, of the Unified Process. Per Kroll, who is responsible for the Rational Unified Processes, and his team is also trying to address this. Reading the current process is like reading source code. We compared source code in a previous post to encryption – contributions from multiple separate domains are intermingled together in the description – and the result is very hard to read, understand and maintain. Ivar has some new ideas that separate the domains of the practices from each other. A practice is described using a set of process cards each including activities, competencies and artifacts. It is great to see that separation of domains is also finding its way into process thinking. And hopefully as we strive for radical simplification in the way we build and use software, our processes will also be radically simplified.

A Story of Four Benches

Hi, my name is Shane Clifford, and I am a developer here at Intentional Software Corporation. The following story is inspired by the work we are doing at Intentional, as well as an experience related by Christopher Alexander in Book 3 of The Nature of Order, at the end of Chapter 11.

---

Once upon a time, there was a village with four neighborhoods. Each neighborhood had a little park that its inhabitants enjoyed, and there was a bit of competition amongst the neighborhoods to have the best park in the village.

One day, during a neighborhood meeting, one of the neighborhoods decided to add a new bench to their park. Before the next meeting, the head of the neighborhood association sent requests to three world-famous bench manufacturers requesting proposals based on their latest designs. At the next neighborhood meeting the three designs, which were the height of fashion in manufactured benches, were presented to the members of the neighborhood. After some consideration and debate, it was put to a vote, and one of the benches was selected with 45% of the vote. Many of the neighbors were unhappy with the selection, but clearly the most popular bench had prevailed through this democratic process. They now had the best park in the village!

Well, one of the other neighborhoods observed what had happened, and they thought, “Surely, we could do a better job of getting a bench we are all happy with, and then we will have the best park in the village!” The head of their neighborhood association found a different bench manufacturer that offered mix-and-match bench components, so you could order a “customized” bench to meet your specifications. The neighbors began to select their favorite components from the various pages of the catalog, but soon discovered that the wood seat slats that they liked did not come in the right length, and the back with the pretty scrollwork did not work with the green legs they liked most. Eventually, they chose some metal slats and different legs; because most people thought they would have the best bench if it had the pretty scrollwork. The bench was installed and the neighbors were very proud of it (but they didn’t sit on it very often.)

A third neighborhood observed what had happened in the first two neighborhoods. At their next meeting, one of the neighbors said, “I bet we could have the best bench in the village if we built it ourselves! Surely, we can do at least as well as the other neighborhoods did, and we can do other things with the money we save.” Everyone thought this was a wonderful idea. A team was put together and—even though no one in the neighborhood had ever built a bench before—they set out collecting the raw materials and putting it together. Occasionally, the team went back to the entire neighborhood to get suggestions on paint color or the height of the back. Eventually, they unveiled a simple, but very beautiful bench in their park, and all of the neighbors were very proud. Their hand-crafted bench was clearly superior to the other two benches. (If you ignored the fact that it wobbled a bit when you sat on it, and didn’t think about the spot on the back where some mistakes had been patched up during construction.)

Now the fourth neighborhood was very unsure about what to do. They did not feel comfortable building their own hand-crafted bench, but also wanted something much better than either the manufactured bench or the mix and match, manufactured component bench they had seen in the other neighborhoods. Finally, at their next meeting, one of the neighbors said, “I saw an ad in the newspaper for a new company that is offering a new bench making experience.” The neighbors were very tentative, and skeptical, but decided it was worth taking a chance in order to outdo the other neighborhoods and also to keep their park a beautiful and special place. They contacted the new bench maker and he asked to attend their next neighborhood meeting.

When he arrived, he had a flat-bed truck with several machines in the back. The bench maker took the floor and immediately began asking questions. “What is the most important feature of this bench for your neighborhood?” Eventually, the neighbors agreed that it needed to be comfortable. “Ok, what is the next most important feature of this bench?” After a lot of discussion, they decided what was really important was that it face toward the most beautiful view in the park.

These questions went on for a while, and soon, the bench maker began arranging his machines in the back of the truck into a new sequence after each question; later, after each question was answered, he turned knobs or adjusted levers on individual machines. Many of these later questions covered somewhat more detailed subjects such as material, shape, color, and height. After about 20 questions, an image of their bench, positioned where they had decided was best, appeared on a large screen on one of the machines. The image changed as each subsequent question was answered. Sometimes, their answers changed after seeing the latest image, and they would backtrack a bit.

Eventually, they discussed much smaller, ornamental details of the bench. Finally, after a few hours, the 50^th question was asked, “What should the shape of the feet be on this bench?” After some discussion with the bench maker and going over several options he presented, the neighbors agreed a particular claw foot complemented everything they had decided up to that point. The bench maker thanked them all for their help, and pushed a button at one end of his series of machines.

The machines hummed for a short while and eventually a beautiful bench that matched the one in the image emerged from the machines. The neighbors installed the bench in the exact place they had selected. They all felt very proud to have taken part in making their bench, and enjoyed visiting the park much more from that day forward.

How is this story relevant?

Christopher Alexander’s A Pattern Language provided well known inspiration for the concept of patterns now widely taken for granted in the software industry. Alexander’s patterns of course were specific to architecture and construction of buildings, but the parallels to software development are easily drawn.

In The Nature of Order, Alexander describes a new fundamental process for architecture and construction that has already inspired new work in software. A good example is Organizational Patterns of Agile Software Development by Jim Coplien and Neil Harrison.

Alexander’s fundamental process is generative, iterative, and transformative. It adheres to a tenet that the owner of a building must be involved in all phases of its design and construction. The same applies to the architect. This does not mean the owner and architect do all of the work. It simply means that they are aware of what is taking place, and are making the major decisions. In his fundamental process, the design of a building neither begins nor ends with drawings. Planning, design, and construction must be intimately intertwined in order to implement a generative approach. This combined activity is called making. Alexander acknowledges that this will also require "ultra-high-tech” materials and equipment and advancements in construction techniques in order to be cost-effective in today’s environment.

In this definition of making, it is theoretically impossible for a successful building to be built from a set of drawings which specify every detail, because that would cripple the capacity of feedback to help shape the elements and details as they are built. […] our 21^st-century techniques allow details to be fitted exactly to their positions in the whole through some new form of almost “biological” process.

–Christopher Alexander, “All Building as Making.” The Nature of Order, Book Three: A Vision of a Living World. Berkeley: CES, 2002.

I see many similarities between Alexander’s fundamental process and the fundamental process Intentional Software enables. When making Intentional Software, the domain experts’ intent is captured in the system in their own domain terminology. The programmers contribute their own expertise both to enhance the expressive power available to the domain experts and to generate an executable system. The software is made through the combined effort and knowledge of domain experts and programmers working on the structured code.

In many ways, we software developers should be better off than building owners and architects. Making software, by its nature, is more readily adaptable to a fundamental process of this sort than is making physical things like buildings. Unfortunately, the software community has not had the technology or process necessary to take advantage of that fact.

We are hiring!

Currently we have openings for a select few outstanding programmers. If you would like to work on a new breakthrough product that will transform how software is used and developed, this is your opportunity. If you are bright, highly competent, willing to take risks and enjoy having fun working together in a team, you will fit right in. Your specific background, your number of years in the industry or the specific technologies you master are less important.

To learn more about Careers at Intentional Software Corporation, click here. And make sure to check out our recruting video!

Petzold's April Fool's Joke

Hope you enjoyed the link to CSAML in our News section.

I think this is a very funny joke. Generally when a joke has to be explained, it is not considered funny, so I am not going to explain it but I’d like to discuss its significance because it relates very much to domain specific languages and to what is wrong with the current implementations.

It is important to realize that Charles Petzold’s examples are nearly real – they employ current techniques that people have to use for domain specific languages out of sheer necessity – but he applies them to the C# language where a highly usable but expensively developed syntax is already available. The contrast between the two - the luxurious C# and the cheap XML - is appalling and we find that funny in a kind of cruel “Upstairs, Downstairs” way – this was the British TV drama where the upper-class household upstairs was in contrast with the lower-class servants downstairs.

With projective systems you can have both great looks and inexpensive implementation. But there are two additional fine points: the source, no matter what is the notation, should not contain information that is computable from the rest. It should contain only things where the user is the only authority – that is the user’s intentions. For example, by this rule we could omit including the information that in the statement A=5/(B+27*C) the operand 27 is a multiplier, unlike in Petzold’s XML statements where an extra <Multiplication.Multiplier> tag was given. That information belongs in the definition of the multiplication, not in the source tree. Otherwise all we have is another hoop that the user and language transforming programs have to jump through.

The other point is that is that the awkwardness of XML and the lack of projections causes the language designers to intermittently fall back into text syntax.This happened, for example in the “Type” attribute of the joke: <Literal Type="{x:Type Int32}"> ; or in the XPath expressions of XSL in real life.

Here is how a similar example looks as an Intentional Tree:

Assign(A, Div(5, Plus(B, Mul(27, C)))

In this instance the Mul definition already knows that the first argument is the multiplier.

When we project it in the Intentional Editor the editable screen looks like this:

Of course many other editable projections are also possible, here are just a few more for fun:

Or:

The interesting point is that even the “not-projected” representation is not at all terrible; it looks a little like LISP. It is not intended for normal use by people; it is a projection of the binary internal representation. The main reason that it looks better than the joke example is that it does not include any information that should be in the schemas, or which is part of the general domain knowledge, in other words it is Intentional. Of course, if you want the real XML syntax, like Petzold joked about, it is just another projection where the schema information is included. And with that you can say you are a real XML programmer with all the scars!

Space News

While I try to keep my private life (such as it is) separate from work, we are getting a lot of hits because of the announcement of the contract I signed for an orbital flight on a Soyuz spacecraft and a visit to the International Space Station (ISS).

For the full press release see Space Adventures.

I want to re-iterate that my main focus before and after the flight remains with Intentional Software. We did not expect to make the space announcement at this time, but the story broke in Moscow so we had to scramble to get some material together. The actual flight assignment has not happened yet, but in any case the flight is not expected before the fall of 07.

I am very excited and feel privileged to participate in this adventure. The engineers and cosmonauts in the Soyuz program are truly an impressive bunch and their booster and spacecraft are marvels of system engineering, meaning that with modest means they created a reliable and still valid design. I am very fortunate to be able to study this system in detail.

Of course I could not resist looking at the components from the Intentional point of view. Look at the following snippet from the checklist:

It has been produced by the Russians using Microsoft Word! While I am delighted of that, I can see that checklists are a very interesting domain which could be generatively connected to the actual flight software; but even just for consistency checks and other configuration reasons, an intentional encoding would be much better than a Word file.

The syntax of the notation is very strict and is used consistently in the over 200 pages of normal and off-nominal (meaning emergency) checklists. In this example, the first line means: Start the timer, turn on KVD BO-SU (docking unit pressure equalization) valve using command C3. Observe light on, if light off (the dark rectangle), we have off-nominal condition (dotted border), action is to communicate with (Dpo) ground control (UZ). The next line is to be executed 1 minute after the first line, and the same valve is turned off. As you can see, it is a very precise domain specific language.