In Eight Hours, $42 Billion Was Gone. Why Big Companies Don't Collapse Slowly, but All at Once
The article explains why large organizations don't fade away gradually but collapse abruptly, like a phase transition in physics — after a long period of apparent solidity, they are set off by a trigger that would not harm a healthy system. Drawing on cases from Silicon Valley Bank and Lehman Brothers to Enron, Wirecard, FTX and Nokia, it identifies three recurring mechanisms (internal rigidity, external interconnectedness and criticality) grounded in complex-systems theory. It also soberly assesses the limits of predicting collapses, from Altman's Z-score to Sornette's log-periodic models, and concludes that we understand the mechanisms but cannot reliably forecast them.
When a Second Look Helps and When It's Just the Same Mistake Twice
Drawing on data from mammography, software inspections, and clinical trials, the article shows that what determines the usefulness of review (an appellate court, peer review, code review) is not the number of reviewers but the mutual independence of their errors. Parallel independent assessment adds up findings, whereas sequential chaining inherits the anchor of the previous verdict and is the weakest; moreover, reconciliation and arbitration mainly serve to remove false alarms rather than to uncover new mistakes. AI can be a valuable second reader only if its blind spots do not overlap with human ones.
Strong Code Ownership Yields the Fewest Bugs, but Also the Most Fragile Teams
The article maps the debate over code ownership in software engineering: according to empirical data from Microsoft, Google, and academic research, strong individual ownership leads to the lowest defect rates and fewer vulnerabilities, but at the same time creates fragile teams with a low bus factor and knowledge silos. Drawing on Fowler's taxonomy (strong/weak/collective ownership) as well as newer models (CODEOWNERS, stewardship, InnerSource, AREA), the author concludes that hybrid approaches combining clear accountability with openness come out on top. The closing recommendations tailor the model to team size, regulation, and architecture (microservices vs. monolith).
COBOL Is Dead, Long Live COBOL! Thirty Years of a Departure That Never Happened
The article takes the April 2020 appeal by the Governor of New Jersey — who during the pandemic publicly sought out programmers of the sixty-year-old COBOL technology — and uses its fate to show why thirty years of announced plans to migrate to more modern systems never came to fruition. Using game-theory models (game of chicken, stag hunt, tragedy of the commons) and behavioral economics, the author explains why legacy-system programmers did not become obsolete but rather scarce and better paid — while also pointing out where this optimistic scenario holds and where, conversely, a fatal ending looms, as it did for Kodak.
Why a New Tool Won't Make You Five Times Faster: Amdahl's Law of Human Productivity
Using Amdahl's law, the article explains why tools like AI for programmers or 3D CAD for engineers deliver far smaller overall speedups than marketing promises — they accelerate only about a third of the work, so even an infinitely fast tool boosts total output by at most tens of percent, and the bottleneck merely shifts elsewhere (from writing code to reviewing and approving it). The author backs this with empirical studies, including the randomized 2025 METR trial, where experienced developers were 19% slower with AI despite believing the opposite, and the "J-curve" phenomenon, where productivity first drops after adoption. According to him, real productivity gains come not from faster tools but from rebuilding the way work is done — and that takes years, not quarters.
Don't deal with technical debt at the end. Deal with it in every commit.
The article argues against deferring technical debt to one-off “hardening sprints”
When a company tests resilience it doesn't have: how a million euros a year vanishes into planned outages
The article criticizes the practice of a Czech technology company that shuts down its data center every two weeks for a resilience test, even though its internal systems (Git, CI/CD, wiki) are not redundant and crash during every test. The author shows that this costs the company over a million euros a year in lost productivity from 600 developers, and compares this approach with the chaos engineering principles of Netflix, Google, and Amazon – which first built redundant infrastructure and only then tested it.
Why Your Company Isn't Doing Agile (Even If It Thinks It Is)
The article analyzes why most companies fail at agile transformation — only 4% achieve enterprise-wide agility. The cause isn't bad frameworks, but deep cultural and organizational barriers: a frozen middle management, a cargo-cult imitation of agile, and missing technical practices. In the Czech context, the situation is made worse by a hierarchical culture rooted in the Austro-Hungarian and communist tradition, with the key to success being cultural change rather than the introduction of rituals.
Who Pulls the Cord? Why Tech Companies Fail When Information Doesn't Flow
Using the Space Shuttle Columbia disaster as a case study, the article analyzes why information flow breaks down in tech companies — middle management filters out bad news, and leadership makes decisions based on optimistically sanitized data. It introduces formal models of information flow (Bell-LaPadula, Biba) and shows how organizational culture determines whether critical information reaches the person making the decision.
From Punch Cards to AI-Native Databases
The article traces more than a century of the history of data storage and processing — from Hollerith's punch cards used in the 1890 US census, through magnetic drums, tapes, and disks, all the way to today's AI-native databases. It describes key technological milestones including the von Neumann architecture, the founding of IBM, and sequential versus direct data access, and explains why the database market has reached 150 billion dollars with PostgreSQL's dominance.
Under the Hood of Relational Databases: Why Pepa in the Warehouse Couldn't Find Your Display
Using the example of warehouse worker Pepa, who couldn't find a display on the shelf, the article explains the fundamental concepts of relational databases — from the distinction between the internal integrity of data (coherence) and its agreement with reality (correspondence), through keys, relationships, and integrity constraints, all the way to the ACID transaction model. It shows why a database can only guarantee the consistency of data against its own rules, but not its truthfulness against the real world, and why this more than fifty-year-old model is still the backbone of most information systems.
Measure Impact, Not Effort
The article argues that technology companies should measure the real impact on the customer, not just internal metrics such as the number of deployments or infrastructure modernization. It introduces a three-layer measurement system (customer metrics, DORA metrics, capacity allocation), prioritization methods such as Cost of Delay and WSJF, and organizational principles such as stream-aligned teams that connect technology work with the delivery of real value.
An Inductive Criterion for the Extensibility of Information Systems
The article proposes using the principle of mathematical induction as a formal criterion for assessing the extensibility of information systems — if adding new functionality requires effort that depends primarily on the feature's own complexity rather than on the state of the system, the system is healthy. It introduces the Development Velocity Ratio (DVR) metric to quantify the slowdown of development and analyzes the technical, organizational, and psychological causes of system degradation, including the impact of AI tools on development metrics.
Why Do M:N Relationships Not Exist in Nature?
The article advances the thesis that in the real world there is only one fundamental relationship cardinality: 1:N. The M:N relationship does not occur in nature — its presence in a data model always signals an incompletely performed analysis and a hidden intermediary (junction) entity. The thesis is supported by a synthesis of relational ontology in philosophy (ontic structural realism, process philosophy), relational theory in computer science (Codd, Kent), and practical experience with data modeling.