Christopher Alexander’s keynote speech at the ACM Convention on “Object Oriented Programs, Systems, Languages and Applications”, (OOPSLA) in San Jose, CA, October 6 - 10 1996. Christopher Alexander connects his architectural work on patterns and pattern languages [03:40] with the field of computing. He introduces the theoretical framework behind his upcoming work, "The Nature of Order" [04:12], and expresses concern about the lack of "living structure" in the modern built environment [05:52]. Alexander emphasizes the moral component underlying his work, questioning if computing patterns also strive to improve human life [13:39]. He discusses the importance of a pattern language's ability to generate coherent wholes [17:32], the recursive structural characteristics related to patterns [21:11], finding objective criteria for "life" in structures [24:57], and the concept of "unfolding wholeness" [41:25]. He concludes by urging the computing community to consider their potential role in creating living structures in the world [59:22].

Transcript : https://www.patternlanguage.com/archive/ieee.html

From Technical Debt to Cognitive and Intent Debt:
Rethinking Software Health in the Age of AI
Margaret-Anne Storey, University of Victoria, Canada
March 23, 2026

Generative AI is dramatically accelerating the velocity of software development, enabling small teams to ship
features at a pace that would have seemed implausible just a few years ago [Peng et al. 2023]. I saw this
firsthand in an entrepreneurship course I taught recently. Student teams were building software products over the
semester, moving quickly to ship features and meet milestones. By week eight, one team hit a wall. Simple
changes were breaking things in unexpected places, and progress had stalled. When I met with them, they
initially blamed technical debt: messy code, hurried implementations, architectural shortcuts. But as we dug
deeper, a different problem emerged. No one on the team could explain why certain design decisions had been
made, or how different parts of the system were supposed to work together. The code might have been messy,
but the deeper issue was that the team's shared understanding, the theory of the system [Naur 1985], had quietly
fragmented. They had also failed to write down or communicate the rationale behind decisions. They had
accumulated cognitive and intent debt faster than technical debt, and it had paralyzed them.
This is not an isolated story [Willison 2026]. Generative AI does not remove the challenges of software
engineering; it redistributes them. In this article, I propose a triple debt model for reasoning about software
health, built around three interacting debt types: technical debt refers to problems in the code layer, cognitive
debt refers to inadequate understanding across a team, and intent debt refers to a lack of externalized rationale,
information that both humans and AI systems need to work safely and efficiently with the code. Technical debt
makes systems harder to change. Cognitive debt makes systems harder to understand. Intent debt makes it
difficult to know what the system is actually for.

A few decades ago, the only well-known way to deliver something to a server, to make it accessible over the internet, was moving files via FTP in Total Commander, FileZilla or FAR Manager, manually copying files and folders from the left pane to the right one. The more advanced among us preferred standard UNIX tools like scp or rsync instead, but the process was essentially the same.

...

The quiet revolution happened in 2000. Not on Windows Server, and not yet on Linux — but on FreeBSD, a UNIX-based operating system that was the default choice for IT professionals long before Linux dominated the space.

FreeBSD is worth a brief aside here, because it differs from Linux in a fundamental way. Linux is a kernel. What most people call "Linux" is actually that kernel combined with a GNU userland, a package ecosystem, and a set of choices that vary from distro to distro — Ubuntu, Fedora, and Arch are all running the same kernel but are meaningfully different systems underneath.

FreeBSD ships as a complete, coherent OS — kernel, userland, base tools, and libraries all developed together, versioned together, and tested together as a single unit. That coherence matters. It's part of why FreeBSD solutions tend to be cleaner and why the base system behaves consistently across installations.

The solution FreeBSD built on top of that coherent foundation was called jails. Announced by Poul-Henning Kamp and Robert Watson and shipped as a native kernel feature in FreeBSD 4.0 in March 2000, jails took the chroot idea and completed it — adding full network isolation, process isolation, and proper security boundaries.

...

Design patterns promise reusable solutions to recurring problems, yet many remain unused, misunderstood, or applied mechanically. This paper argues that patterns often fail because they insufficiently account for the umwelt—the situated perceptions, experiences, intentions, and values of authors, designers, users, and the contexts in which patterns are enacted. Building on Christopher Alexander’s notion of living structure, we reconceptualize patterns as potentials rather than finished solutions: seeds that must be unfolded through situated design decisions. We identify common “pattern smells” that hinder effective use and show how attention to unfolding, roughness, and contextual fit can make patterns more resilient and meaningful. Extending this perspective, we emphasize the importance of vividness in pattern descriptions—clarity, conciseness, and expressive forms of representation that engage designers, invite reflection, and support learning across diverse umwelts. We conclude with guidance for writing, maintaining, and evolving patterns so that both their descriptions and implementations remain alive, adaptable, and capable of resonating with changing environments and practices

Open Buro

The open European standard for workplace orchestration.

Open Buro is the missing layer that turns isolated open source workplace apps into a unified digital platform — capable of rivaling Microsoft 365 and Google Workspace, without vendor lock-in.

The Problem

Europe has mature open source alternatives for every workplace function: email, documents, project management, video conferencing, chat, calendar. But these tools remain isolated silos. Even with SSO, users get an app catalog — not a platform.

Meanwhile, dominant suites win not because they're better app-by-app, but because they deliver a platform effect: an interlocked ecosystem where everything flows together effortlessly. Leaving becomes perceived as risk, not a project. The dependency is strategic and political, not just budgetary.

The Standard

Open Buro defines how independent open source services assemble and communicate through a common orchestration layer. The standard covers 7 domains:

• Application Integration — Unified SSO, standard app packaging, centralized registry, common settings API
• Cross-service Navigation — Shared home screen, unified nav, global app grid, cross-app command palette
• Data Intelligence — Business object definitions, cross-app event streaming, knowledge graph, unified search
• Platform Collaboration — Cross-service workspaces, threaded comments, unified notifications, shared presence
• Inter-apps & AI — Capability/intent casting, shared file picker, AI agents orchestrating across tools
• Security & Encryption — Platform-level E2E encryption, granular permissions, audit logging
• Mobile & Desktop — Native mobile apps, desktop client, browser extension

The Alliance

The Open Buro Alliance is the collective movement — publishers, institutions, governments — that governs and promotes the standard. Structured as a neutral foundation (modeled on Linux Foundation / CNCF), no single vendor controls the standard.

Founding members:

• Twake (LINAGORA's collaborative platform)
• La Suite numérique (DINUM, French government digital workplace)

We are at the very beginning, join us !

Au delà de la pyramide des tests.

Des propriétés désirables de tests.

• make it wrong
• make it short
• make it again

npx difit

Trancher dans n'importe quelle situation

Maximizer : comparer au max les choix, opimiser pour faire les meilleurs choix

Satificier : cherche juste un bon chois, décident vite, moins de regret post-décision, et sont plus heureux.

Si un choix peut être réversible, il doit être pris comme une expérience et être fait le vite possible

Si un choix est irréversible, prendre sont temps et réfléxhir à fond

• complexity is the default condition
  • complexity will grow
  • entropy will increase
• local decisions will get made will appear to make sense locally will not roll up will clash at the edges
• we we always have the choice to simplify if we can recognize where the complexity is and if we can arm ourselves with techniques that are going to help us do that
• consistency is the key
  • consistency is the mechanism by which we can make we can reduce cognitive load we can or make cognitive load appropriate
• some problems are intrinsically hard, that's fine
  • they don't need to be any harder than they are

it really shouldn't be this difficult

We have two options for defining types in TypeScript: types and interfaces. One of the most frequently asked questions about TypeScript is whether we should use interfaces or types.

The answer to this question, like many programming questions, is that it depends. In some cases, one has a clear advantage over the other, but in many cases, they are interchangeable.

In this article, I will discuss the key differences and similarities between types and interfaces and explore when it is appropriate to use each one.

Let’s start with the basics of types and interfaces.

When to use types vs. interfaces

Type aliases and interfaces are similar but have subtle differences, as shown in the previous section.

While almost all interface features are available in types or have equivalents, one exception is declaration merging. Interfaces should generally be used when declaration merging is necessary, such as extending an existing library or authoring a new one. Additionally, if you prefer the object-oriented inheritance style, using the extends keyword with an interface is often more readable than using the intersection with type aliases.

Interfaces with extends enables the compiler to be more performant, compared to type aliases with intersections.

However, many of the features in types are difficult or impossible to achieve with interfaces. For example, TypeScript provides rich features like conditional types, generic types, type guards, advanced types, and more. You can use them to build a well-constrained type system to make your app strongly typed. You can’t do this with interfaces.

In many cases, they can be used interchangeably depending on personal preference. But, we should use type aliases in the following use cases:

• To create a new name for a primitive type
• To define a union type, tuple type, function type, or another more complex type
• To overload functions
• To use mapped types, conditional types, type guards, or other advanced type features

Compared with interfaces, types are more expressive. Many advanced type features are unavailable in interfaces, and those features continue to grow as TypeScript evolves.

Below is an example of the advanced type feature that the interface can’t achieve.

type Client = {
    name: string;
    address: string;
}
type Getters<T> = {
    [K in keyof T as `get${Capitalize<string & K>}`]:  () => T[K];
};
type clientType = Getters<Client>;
// type clientType = {
//     getName: () => string;
//     getAddress: () => string;
// }

Using mapped type, template literal types, and keyof operator, we created a type that automatically generates getter methods for any object type.

In addition, many developers prefer to use types because they match the functional programming paradigm well. The rich type expression makes it easier to achieve functional composition, immutability, and other functional programming capabilities in a type-safe manner.