The usual way of reading power treats it as a possession. Someone holds the leverage or they do not; the troops, the money, the umbrella, the seat at the head of the table. On that picture the strong actor is the one who can hurt the others more than they can hurt back, and the others arrange themselves accordingly because they have no better option. It is a tidy model, and it is wrong in a particular way that takes a while to show. ...
Everyone knows by now that Europe is rearming. That part is easy to write and carries almost nothing, because “investing in defence” survives any amount of vagueness. The interesting reading sits a little lower down, in the documents that have to name things: how much money, raised in what way, spent on what, through which legal route, under whose command. Those are harder to write and harder to take back, because somebody has to act on them. Read side by side, they sketch a shape, and the shape says more than the announcements do. ...
A policy speech says what an institution wants to be seen wanting. A procurement document records what it has agreed to pay for. The two are not the same, and the gap between them is usually the more interesting reading. A press release costs nothing to write and binds no one. A call for tender names a budget, a deadline, a set of deliverables and a contract that someone will sign and then have to deliver against. Intentions are cheap. Commitments leave a paper trail, because somebody has to do the work and somebody has to account for the money. ...
Er is een gewoonte in detection engineering die een organisatie tijd kost om af te leren. Een team kijkt naar de waarschuwingen, de dashboards en de dekkingsrapporten, en beschouwt die als de plek waar detectie gebeurt. Dat is niet zo. Het is de plek waar detectie zichtbaar wordt. Het werk dat bepaalt of er iets te zien valt, gebeurde veel eerder en veel stiller, toen iemand koos wat er gelogd werd. Zonder vastgelegde gebeurtenis genereer je geen waarschuwing. De prijs van een ontbrekende log betaal je pas tijdens een incident, wanneer blijkt dat het spoor nooit heeft bestaan. ...
The stability of dysfunction Many discussions of large systems quietly assume that a stable system is a healthy one, and an unstable system is a sick one. Complex systems tend to violate that intuition. They can remain operational for a very long time without becoming any healthier, and they possess several mechanisms that let them do so. Normalisation is one of those mechanisms. It is not the whole story. The whole story, if there is one, is that persistence and health are different properties, and large systems are often much better at achieving the first than the second. ...
Many critiques of Agile assume something went wrong. The story is usually told as a fall from grace: a practical response to software uncertainty that then disappeared beneath ceremonies, certifications, frameworks, and consultants. There is another way to read the same history. Perhaps Agile did not fail. Perhaps it succeeded, and what happened next is simply what institutions do to successful ideas. On that reading the interesting question is not why Agile became institutionalised. It is why successful ideas so reliably do. ...
Most engineering disciplines accept that method follows from context. Nobody expects a bridge engineer, a documentary director, and a trauma surgeon to share a planning model, and nobody finds the difference remarkable. Software is one of the few fields where people go looking for a single methodology and then try to apply it to everything in sight. Agile is the most successful instance of that search, which makes it an awkward thing to argue about. The useful question is not whether it is good or bad. It is what kind of work it was meant for, and that turns out to depend on two things that have nothing to do with how much anyone likes the method. ...
Few movements in software have been as successful as Agile. What began as a reaction against heavyweight process, exhaustive documentation, and centralised planning became the dominant way organisations talk about building software. And somewhere in that success it acquired certifications, prescribed ceremonies, maturity models, governance structures, a consulting industry, and dedicated management hierarchies, which is to say it acquired most of the things it was a reaction against. The question worth asking is narrow. Not whether Agile succeeded, and not the broad point that institutions reshape ideas, but the specific mechanism. By what steps does a critique of bureaucracy turn into a bureaucracy, when nobody involved wanted that outcome? ...
A friend asked whether the proof-of-concept I had sketched on a docs page was worth actually building. I said no, for the usual reasons, and also because the page in question had been written in the specific style of a document that does not want to be read. A four-layer architecture diagram without the diagram. Ingestion, storage, correlation, presentation. Bullet lists of API names with the dispiriting authority of a railway timetable. It reads like a tender response written by a tender response. ...
The story is, on paper, narrow. Solvinity, the Dutch contractor that operates infrastructure underneath Logius and DigiD, looks set to be acquired by Kyndryl, an American spin-off of IBM’s managed-services arm. DigiD itself remains owned by the Dutch state via Logius, so technically the system is still Dutch. Politically and operationally, the distinction does not calm many people down. A rented engine room is still part of the ship. Across Europe there has been a push for “digital sovereignty”, meaning less dependency on American hyperscalers and infrastructure providers after years of quietly outsourcing half the state to Silicon Valley with the serene confidence of a man juggling chainsaws because the first three catches worked out fine. ...