Antifragility in IT: Hypotheses Instead of Specs

The host and the guest first met at a conference in Berlin, where a large round table split into defenders of the monorepo and of many small repositories; the guest still remembers his surprise that half the table spoke Russian, and calls it a frame from a previous life, when the community was a short flight away. He describes himself in broad strokes: for twelve years he has run his own IT company, now six or seven people, taking a product from the words 'we have a problem' to a release across the country, alongside consulting, teaching at universities and free mentoring on one platform. His second book, about the hypothesis map, has just come back from the printer. Alexander opens with his objections: in places the writing is too terse, the references run three or four to a page in the teaser half, and the classification of customers in the first chapter is plainly incomplete.

The guest answers straight: the book was not written for Alexander or people like him. Team leads and tech leads have been through all of it already; he wrote for those still at university, for newcomers who need to grasp the breadth of the profession, and for the layer above IT — executives, business owners and investors who watch development from a distance. Hence the chapter on why projects fail: people come to him saying they are ninety-five per cent done and out of money, he opens the code and finds chunks of static HTML and something spinning at the bottom — the system was never started. Button thinking grew from the same pain: a customer brings a solution, 'add a button here', instead of a business goal, and the team is used as hands rather than as a head. Alexander recalls his own customer who, after a walkthrough of MVC, asked for a universal controller.

The guest started using impact mapping ten or twelve years ago, a couple of years after the book by Gojko, whose surname nobody managed to pronounce on air; it tied a stated goal to a list of tasks, and that alone was a relief. Over the years he kept adding corrections: describe the goal properly, at least by SMART; actors are not the people who do the work; impacts are better written as hypotheses in a defined format. He grew tired of explaining the same things and decided to give the reworked idea a new name — that is how the hypothesis map appeared. He has a Miro template but never submitted it to the extensions catalogue, and on air he invites listeners to do it for him, promising applause; the knowledge base for the map lives on GitHub. The tool looks simple and is hard to fill in, though a friend's twelve-year-old son used a draft to map a school project and defended it.

Alexander holds the map against his own work: he owns a product analytics platform and keeps seeing experiments nobody can revisit later to see what was hoped for. The guest clarifies that his hypotheses sit at the level of strategy rather than statistically significant A/B tests. People from a large oil company tell him the opposite story: the goals are clear and the tasks are laid out ten years ahead, but the link between them is missing, because thinking in hypotheses runs backwards and is genuinely hard. The participants then walk the process slot by slot: OKRs cover goal setting only and ignore strategy and tactics, so the hypothesis map goes on top; the guest replaced the customer journey map with an experience process map — a hybrid of the journey map and a service blueprint, described in detail by Andrey; user story mapping they left alone. For a warehouse management system built for international retail, the simple tools do not stretch.

Antifragility is raised by the guest himself: it underpins the chapter on the specification. Writing a spec means trying to can randomness, promising that everything will be as written, while both sides know that is untrue. Risk reduction is asymptotic: for the same effort risks fall by seventy-five per cent, then by eighty-three, then by eighty-five — like every next nine of reliability. The owner of a large jewellery company brought him a spec of some seven or eight hundred pages that took a year to write and another year to implement, and the business users could not use the result. Alexander adds the mathematics: completeness cannot be proved, and he recalls the incompleteness theorem and the early twentieth-century attempt to derive a complete and consistent arithmetic. The guest jokes that he will now answer every request to estimate against a spec with a link to that theorem, after which people will simply stop replying to him. Sometimes a spec is genuinely needed: when a proxy manager, or two, stands between the customer and the team, when nothing beyond the stated task is expected of the contractor, or when regulations demand it.

The guest puts the point of antifragility plainly: if nothing ever changed, no practices and no architecture would be needed — just slap on new functions; everything starts with the first extension, and the question is whether the business, the people, the teams, the processes and the architecture come out stronger after a change. He recalls a man from a very large company who came up after a talk: if the people vanished overnight, the systems would run for about an hour, counted from incident frequency. To the three Fs the guest added a fourth: quality is always fixed, otherwise the first change of direction costs three or four iterations and sounds like 'Scrum does not work', when the real diagnosis is internal quality. Alexander recommends the book by a Stanford lecturer who devised the raft algorithm, the guest an article by Fowler on the cost of internal quality. A diagram from the book maps awareness against competence: people have to be pulled deliberately into conscious competence, or the curse of knowledge blocks handing context on. They close with a trust and transparency matrix: a flexible scope only works at high trust, which grows through standups, demos and the habit of bringing problems first.