Software-Architecture

On why large organizations structurally produce technical debt, select for political behavior, and reliably defeat every attempt at reform, including Agile. I have watched a pattern repeat itself across organizations too many times to believe it is accidental. A technically competent person does careful work, raises legitimate concerns about architectural shortcuts, pushes back on timelines that will generate problems downstream. They are right. Their concerns are documented. And they are quietly sidelined while the project proceeds, delivers on schedule, and the manager who overrode their concerns is promoted. ...

The Tipping Point What AI Cannot Replace in Software Development, Part 3 In a previous article in this series, I proposed a redefinition of legacy: legacy is not a property of the code itself, but a state of the relationship between the code and those expected to maintain it. A system becomes legacy the moment no one in the organization mentally inhabits what they are nonetheless expected to evolve. The problem lies less in the age of the technology than in the developer’s lack of deep cognitive engagement with their own code. ...

What AI Cannot Replace in Software Development, Part 2 What the developer must retain, what can legitimately be delegated, and why confusing the two leads to the erosion of knowledge. An Operational Distinction I have spent a significant part of my career working with organizations whose human foundation is unstable: high turnover, frequent reassignments, temporary teams assembled for a project and dissolved at its close. In these organizations, something specific happens to software systems over time. The knowledge of why the code is the way it is gradually disappears. ...

What AI Cannot Replace in Software Development, Part 1 A perspective on the structural limits of automated test generation, and what they reveal about the nature of work in software engineering. The Problem Nobody Names A few years ago, I reviewed a software development contract between an organization and a vendor. The terms were standard: a fixed delivery date, a penalty clause for late delivery, and an obligation to maintain 80% code coverage. The intent was twofold. It would protect the organization from negligence, and guard against the kind of deliberate opportunism that governance frameworks exist precisely to prevent. ...

A sociotechnical perspective on what makes code legacy, and what actually keeps it alive. In the organization where I work, there is a mainframe COBOL system that has been running at the core of operations for decades. By every conventional definition, it should be legacy: old language, old architecture, a technology that most developers under forty have never touched. It is not legacy. The team responsible for it is among the most mature and capable in the organization. They understand every decision embedded in that system: the constraints that shaped it, the business rules it encodes, the edge cases it handles. They can explain why a specific field is structured a certain way, what regulatory requirement drove a particular branching condition, and exactly what would happen downstream if you changed it. There is no question about the system they cannot answer. ...

Part IV of a series on rethinking technology governance foundations, and a pivot toward what comes next The first three articles in this series examined specific symptoms: the instability of the People-Process-Tools model under high human variability, the strategic liability of tool positioning in a fast-moving AI market, and the asymmetric risk that regulated organizations are structurally failing to measure. This fourth article steps back to name the underlying condition, the diagnosis from which those symptoms follow. ...

Rethinking the foundations of technology governance in an era of structural human variability A Time-Tested Model Confronting an Unprecedented Context The People, Process, Tools (PPT) model has shaped technology governance for decades. Its founding premise rests on the stability of human capital: skilled individuals, carrying a shared culture, apply defined processes using adapted tools. In its mature form, this model has always recognized that processes and tools encode organizational knowledge, with the human dimension serving as the activation vector. ...

Part II of a series on rethinking technology governance foundations In a previous article, I argued that the People-Process-Tools model needs to be rebalanced toward platform engineering in contexts of high resource variability. This article extends that argument one step further: in a world where AI is redefining the available tools every few months, even the ‘Tools’ layer of that platform deserves to be rethought. The Paradox of Tool Positioning In large organizations, the process of selecting, evaluating, approving, and deploying a new tool is rarely a lightweight exercise. Between security reviews, architecture assessments, procurement cycles, integration planning, and training programs, the full lifecycle from initial evaluation to production readiness commonly spans six to eighteen months. For highly regulated environments, that timeline can extend further. ...

On Creativity, Metaphor, and What AI Still Needs to Learn A Theory of Creativity First Before building any system, I needed to understand what creativity actually is. Here is the formulation I arrived at around 2005, working as a researcher in Québec City: Humans cannot create something entirely new from nothing. We can only perceive reality through our senses. You cannot imagine a color that does not exist. You cannot conceive a sound you have never heard. The entire domain available to human creativity is bounded by accumulated sensory experience. ...