Updated on 24 min read
Sébastien Nobour
Founder of DEVEDANOS
The video game Grand Theft Auto VI was due out in 2025; after two delays, it is now announced for 19 November 2026. In the Saudi desert, a city 170 kilometres long was announced in 2021; work on it has reportedly been pushed back until after 2030. In Senegal, a new city announced at six billion dollars is to be replaced by a property development. And in France, Canada and the United Kingdom, public auditors describe the same pattern in IT.
These projects have nothing in common but one thing: a date and a budget announced for a piece of work that had never been carried out before, and that called for design, research and construction.
Grand Theft Auto, or GTA, is a video game franchise from the studio Rockstar Games, published by Take-Two Interactive. It is not new: since 1997, it has comprised seven main instalments, and around fifteen games once expansions and spin-offs are counted (Wikipédia). On 4 December 2023, the first trailer for the sixth instalment was viewed more than 90 million times on YouTube in 24 hours, a record according to Guinness World Records. It announced a release in 2025.
Here is every date announced since, and every confirmation, as published by the publisher and the studio:
| Date of announcement | Announced release | What was said |
|---|---|---|
| 4 December 2023 | 2025 | Take-Two press release |
| 2 May 2025 | 26 May 2026 | First delay, announced by Rockstar |
| 7 August and 10 September 2025 | 26 May 2026 | Take-Two repeats the date in its quarterly results, then in an investor presentation |
| 6 November 2025 | 19 November 2026 | Second delay, on the day of Take-Two’s quarterly results |
| February to October 2026 | 19 November 2026 | Take-Two repeats the date with each set of results (February, May, August), then the launch trailer of 15 October keeps it |
This date does not only matter to players. In its August 2026 results, Take-Two maintained its sales forecast for the current financial year, between 8 and 8.2 billion dollars, citing the 19 November release.
From one instalment to the next, a great deal is repeated. But GTA VI opens a new era, a new generation of the franchise, more than ten years after GTA V, released on 17 September 2013. That is what makes it a new piece of work, not a repeat. Every date in this table was an estimate, and each was presented as a deadline.
On 10 January 2021, Saudi Arabia’s crown prince, Mohammed bin Salman, announced The Line, a city running in a straight line for 170 kilometres within NEOM, a development zone in the north-west of the country (Gulf News). On 25 July 2022, he unveiled its designs: 200 metres wide, and eventually 9 million residents (Khaleej Times).
| Date | What has been announced or reported since |
|---|---|
| April 2024 | According to Bloomberg, citing anonymous sources, only 2.4 kilometres would be completed by 2030 (reported by Dezeen) |
| January 2026 | According to the Financial Times, The Line would be redesigned as a far more modest project (reported by Archinect) |
| 22 May 2026 | According to Semafor, citing anonymous sources, work is postponed until at least after 2030 (Semafor) |
As of 20 October 2026, no official cancellation has been announced: according to the Saudi sovereign wealth fund, NEOM projects have been delayed, none cancelled (AFP, reported by Macau Business). Contracts have nevertheless been terminated, including the one for boring its tunnels (MEED).
In Senegal, Akon City, the project of the singer Akon, who gave it his name, was to rise on 800 hectares at Mbodiène, south of Dakar. Announced in June 2018, it was costed at six billion dollars, with a first phase planned for the end of 2023 (BBC, reported by Capital FM). By 2024, only the shell of a reception building had gone up (Ecofin). On 26 June 2025, the public tourism development agency declared: “The Akon City project no longer exists.” (“Le projet Akon City n’existe plus.”, in French) A property development is to replace it (Le Soleil).
The pattern is the same: a vision made public with its figures, then targets scaled back, one after another.
No. It is where failures are most common. Bent Flyvbjerg, a professor at the University of Oxford, studied 4,677 IT projects: the average overrun reaches 80% of the quote (Flyvbjerg et al., 2022). We go into these figures in our article on why software projects go over budget. Public projects show it better than others, because their accounts are published.
In France, the Ministry of Education launched SIRHEN in 2007, a system for managing its human resources budgeted at 60 million euros. Stopped in July 2018, the programme had cost more than 400 million euros. The Cour des comptes, the French public audit court, called the initial estimate “unrealistic” (“irréaliste”, in French) (2020 annual public report).
In Canada, Phoenix, the payroll software for federal public servants, was budgeted at 155 million Canadian dollars (Senate of Canada report, 2018). Put into service in 2016, it piled up pay errors; by 2025, fixing them had cost more than 5.1 billion dollars (The Canadian Press).
In the United Kingdom, the programme to computerise the national health service was meant, among other things, to give hospitals an electronic patient record; the suppliers did not manage to roll it out in full (The Register). Dismantled in 2011, it saw its forecast cost rise from 6.4 to 9.8 billion pounds, for benefits estimated at 3.7 billion up to March 2012, about half of what had been spent by then. Richard Bacon, an MP on the House of Commons Public Accounts Committee, called it “one of the worst and most expensive contracting fiascos in the history of the public sector” (National Health Executive).
Did you think these were isolated cases? Think again. It happens far more often than you think, and these overruns have a common cause.
A game, a city, public software: in each of these projects, the date and the budget rest on an estimate that people believe to be reliable. It is not.
What is redone identically becomes predictable, and in fact we end up automating it. Software, on the other hand, is always developed for the first time. Otherwise, we would simply install it. Each of these projects is a work no one had carried out before. Estimating how long it will take amounts to making a guess.
Science explains why. In 1972, the physicist Philip Anderson (Nobel Prize in Physics, 1977) published “More is Different” in the journal Science. His thesis: at each level of complexity, new properties emerge that cannot be predicted by studying the parts in isolation. Chemistry is not applied physics, nor is biology applied chemistry. A work that has never been designed is not a sum of tasks to be priced one by one: it is not car mechanics, and it cannot be estimated reliably. For their part, the psychologists Daniel Kahneman and Amos Tversky described, at the end of the 1970s, what they called the planning fallacy: even when we know that similar projects overran their forecasts, we underestimate the time and cost of our own. Common sense knew this long before science did.
So why do we carry on? The practice comes from manufacturing. The worldview behind it is much older. It comes down to two ideas: a problem is solved by breaking it into parts, and whoever knows the present well enough can predict the future.
In 1637, in the Discourse on the Method, the philosopher René Descartes set himself, as his second rule, “to divide each of the difficulties I would examine into as many parts as possible, and as would be required to resolve them better” (“de diviser chacune des difficultés que j’examinerois, en autant de parcelles qu’il se pourroit, et qu’il seroit requis pour les mieux résoudre”, in French) (Wikisource). The mathematician Pierre-Simon de Laplace, in 1814, took the other idea to its conclusion. He drew on astronomy and on the law of universal gravitation, Newton’s law. An intelligence that knew, at a given moment, all the forces of nature and the position of every thing could, in his view, calculate everything: “nothing would be uncertain for it, and the future, like the past, would be present to its eyes” (“rien ne serait incertain pour elle, et l’avenir comme le passé, serait présent à ses yeux”, in French) (Wikisource). This is determinism: what will happen follows from what is, and can therefore be predicted.
Economists then applied this division to manufacturing. In 1776, Adam Smith opened The Wealth of Nations with a pin factory. There, the business of making a pin is “divided into about eighteen distinct operations”. Ten workers produce “upwards of forty-eight thousand pins in a day”, whereas each of them, alone, might not have made twenty (Project Gutenberg). In 1832, the English mathematician Charles Babbage took up Smith’s example in On the Economy of Machinery and Manufactures. For each operation in pin making, he drew up a table “of the time occupied by each process, and its cost” (Project Gutenberg). Whoever knows the time and cost of each operation can calculate in advance what the whole manufacture will cost.
Nothing proves that Frederick Winslow Taylor read Babbage. Management researchers nevertheless see Babbage as a pioneer of production organisation (Lewis, 2007). It is very likely that these ideas reached Taylor through the engineering circles of his time, where measuring manufacturing costs was becoming a subject in its own right. In May 1886, in Chicago, the industrialist Henry Towne presented a paper entitled “The Engineer as an Economist” to the American Society of Mechanical Engineers, the ASME. In it, he called on engineers to take charge of running workshops as well, and to measure their costs. The record of the meeting lists Taylor among the engineers who took part in the discussion (Transactions of the ASME, vol. 7). In 1921, an industrial journal considered that this paper had “probably inspired” Taylor to devote his life to workshop organisation (Wikiquote).
For making pins by the thousand, this worldview is highly effective: every movement is repeated, so it can be measured and predicted. Taylor turned it into a management method. It is this method that, to this day, is used to plan works no one had yet carried out.
At the start of the 20th century, in the American workshops and steelworks where he worked, the engineer Frederick Winslow Taylor founded scientific management: each task is timed, then prescribed in advance. In his 1911 book, he wrote that the task specifies “not only what is to be done but how it is to be done and the exact time allowed for doing it” (Project Gutenberg). Henry Gantt, whose chart is still used to plan projects, started out as Taylor’s assistant (Wikipedia). Fixing in advance the duration and content of a work never carried out is nothing more nor less than Taylorism, applied to what does not repeat.
Frédéric Leguédois, an agile coach and trainer, addresses this point in his talk “In Praise of Simplicity” (“Éloge de la simplicité”, in French). In an unpredictable context, he says, predictive approaches “are far closer to divinatory practices than to a scientific approach” (“s’apparentent bien plus à des pratiques divinatoires qu’à une approche scientifique”, in French).
Just because everything can be calculated does not mean everything is worth calculating.
We are often asked for figures. People want to run things on figures, believing they are doing science. But by insisting on figures at any cost, we have ended up doing numerology.
Some teams have stopped estimating and count finished features instead, to project their pace onto what remains. That is sounder than a guess, but it is still a prediction, as we explain in our article on the predictive and the adaptive approach.
These dates and budgets do not stay in the office: they are announced. Announcing to the public a date you cannot guarantee, whether for a game, a city or software, means asking those waiting for it to be patient, and asking investors to bet on a work that does not yet exist, counting on a return by that date. It is therefore making a promise. And when you know it is unrealistic at the moment you announce it, to win investors’ confidence, it is not a promise, it is deception.
We do not know what the publisher of GTA VI knew at each announced date. On 10 September 2025, Take-Two was still presenting investors with a GTA VI release on 26 May 2026. Eight weeks later, the release moved to 19 November 2026.
In marketing, lying has become commonplace: people distinguish big lies from small ones, as if the small ones had no consequences. In reality, there is no distinction to be made between the two.
Seen from the side of those to whom these promises were made, the players who waited, the investors who built their forecasts on that date, whoever made the promise loses credibility. And for taxpayers, who see their money swallowed up by projects that end up abandoned, it is unacceptable. It is a lack of respect for one’s neighbour, and for oneself.
There is always an alternative. Let us stop selling people dreams. Let us stop deceiving them. Let us under-promise and over-deliver, instead of over-promising and under-delivering.
The game has to move forward, of course. But if you do not know how long its development will take, and if you refuse to make unrealistic promises, how do you go about it?
First, you develop in a controlled, restricted and confidential environment, so that the game is playable as early as possible: not 100% of the story, but a part that is genuinely finished, 10% of a game that works. If funding is needed, a handful of trusted investors play this private version, which proves that money can already be made with what is finished. They decide to keep investing in a usable game, not in a schedule.
Meanwhile, you communicate a great deal about everything that can be disclosed, without mentioning anything confidential: real footage from the game, behind-the-scenes looks at its design. The public sees that the game is still in development, that the team is facing difficulties, and that it is moving forward. The message is simple: judge for yourselves, the game is already remarkable as it progresses. Investors, for their part, see that players cannot wait to get their hands on it.
Only at this stage does the question of the date come up, and it is no longer essential. A firm date can only be met for a game that is already finished. If you insist on giving one, you give an approximation, a range: a release targeted between one quarter and another, presented as an objective, not as a promise. And you immediately reassure with what is certain: this part of the game is finished, and players are waiting for it.
Some studios already work this way, selling their unfinished game in “early access”, then completing it through updates.
Larian Studios put Baldur’s Gate 3 on sale in early access on 6 October 2020, with only its first act, around 25 hours of play (Game Informer). The full game, released on 3 August 2023, was named Game of the Year at The Game Awards 2023 (TechRadar).
Supergiant Games opened Hades in early access in December 2018, then released a major update “every month or two”, according to its creative director, Greg Kasavin (GeekDad); the game passed a million copies sold a few days after its release, in September 2020 (PC Gamer).
The studio behind Factorio published, every Friday from 2013, what had moved forward during the week, right up to the final version in 2020 (Factorio).
The Korean publisher Krafton takes the approach to the extreme with inZOI, a life simulation game in the vein of The Sims. The game came out in early access on 28 March 2025, with a public roadmap, and its studio announced that it wanted to “continue to actively communicate with players” (Krafton). It sold a million copies in a week (ActuGaming). Some feel that showing everything like this kills the surprise. We would not go that far, but it is a possibility, and the game has found its audience.
The Manifesto for Agile Software Development puts it in one sentence: “Working software is the primary measure of progress.”
Many progress reports measure something else. Take round numbers: a list of 100 features, drawn up at the start of the project. After a few months, 50 of them are half developed. The report announces 25% of the project done, or half of the features started. Yet none of them can be used. If the budget runs out that day, there is nothing usable to put in users’ hands, and nothing that can be sold.
That is the report of the predictive approach: a complete list drawn up in advance, and progress counted as a percentage of that list. The adaptive approach, by contrast, does not start with a list of everything the application will have to do. It starts with a question: what do users need for a first, minimal promise to be kept? The answers form the minimum viable product, the MVP: a few essential features, chosen with users and on the best information available.
These are finished completely, software quality included: the software must be able to evolve easily after users’ feedback, since these features become its core, as Allen Holub, an American developer and trainer, explains (blog.holub.com). This puts a real, usable product in the hands of users and customers as early as possible.
From then on, it is their needs that guide what comes next. Over the life of the software, many features will be added, others will evolve, and others again will be removed because they serve no purpose: the project does not stop at the MVP. What comes next is planned, but by priority: for each need, we ask what it costs not to have it in service yet. This order of priorities stays flexible, to keep the ability to adapt to reality rather than follow a route that leads to failure. That is how an application becomes fully usable without a list of 300 features drawn up in advance. And if the budget runs out along the way, what is in service is already useful, and can be sold: the investment is not lost.
A confidential project does not have to be shown to the public. Its progress is still measured by usable software: those who have to judge that progress use it in real conditions. A demonstration is not enough. In many projects, the demonstration, led by the project manager, commonly follows a prepared path, one that goes through what works and avoids the defects that would reveal the application is not yet usable, and therefore not finished. Only real use shows where the software stands. For your application, then, the first question is not “how many features?” but “what do your users need to get started?”. In a cathedral, it was the choir.
Behind these postponed dates lies a question about human nature: the constant need to know the future, to seek predictability.
Let us turn to an ancient book, a book of wisdom that, despite being more than two thousand years old, is still relevant: the Bible. In the Gospel of Matthew, chapter 6, verse 34, we read: “So never be anxious about the next day, for the next day will have its own anxieties. Each day has enough of its own troubles.” (“Et ne vous inquiétez jamais du lendemain, car le lendemain aura ses propres inquiétudes. À chaque jour ses problèmes.”, in French) In other words: deal today with what can be done about today’s problems.
Frédéric Leguédois quotes this same verse in his talk “In Praise of Simplicity”. In it, he also describes a project schedule: “A schedule is a heap of information that is useless today and wrong from tomorrow onwards.” (“Le planning, c’est un amas d’informations qui sont inutiles aujourd’hui et qui sont fausses à partir de demain.”, in French)
Let us acknowledge, with modesty, that we are not in control of everything. Claiming otherwise amounts to selling a certainty no one has.
Letting go of predictability does not mean moving forward haphazardly. It means preparing differently, anticipating differently. In fact, what is commonly called a plan, a schedule drawn up in advance, is not one. In cartography, a plan represents ground that has already been covered: to draw the plan of a city, you must have walked it and measured it. No measurements, no plan. Yet the schedule for a work never carried out describes ground no one has walked yet. Allen Holub writes about roadmaps: “A roadmap is a bet, not a plan” (LinkedIn).
Letting go means accepting reality as it is, so as to focus on what matters, rather than discovering after the fact that the promise could not be kept.
How do you manage uncertainty when you are building what no one has built before? Let us look at how cathedrals were built. Gothic cathedrals are recognised as unprecedented works, and some were for centuries the tallest buildings ever made by human hands. How were they financed? Who decided their plan? How was a building site run across several generations of builders? Medieval accounts have come down to us only in part, but what remains shows real know-how.
The money. A cathedral was built with the money that came in: the revenues of the bishop and the canons, the priests attached to the cathedral, and the gifts and bequests of the faithful (Vroom).
In Strasbourg, canons founded the Œuvre Notre-Dame in 1226, an institution responsible for financing the building work. It still exists, run by the city, and donations still provide part of its income (City of Strasbourg).
In Chartres, after the fire of 1194, rebuilding went quickly thanks to the “enormous financial resources the canons had managed to raise” (“énormes moyens financiers qu’avaient su réunir les chanoines”, in French) (Encyclopædia Universalis). According to an often-repeated tradition, the town’s merchants are said to have donated 42 stained-glass windows (World History Encyclopedia); historians disagree, some seeing them instead as gifts from the chapter.
It would also seem that the Church encouraged donations through indulgences: for Troyes, a survey of archives published by a local history website cites papal legates granting them, as early as 1213, to those who contributed to the costs of the building work (Aube Généalogie).
In Laon, according to an account written some thirty years after the events, canons are said to have carried the relics of their burnt cathedral through northern France and southern England, in 1112 and 1113, to raise funds (Wikipedia).
When money ran short, work slowed down, and sometimes stopped for a long time.
The plan. It was not fixed on the day the first stone was laid. In Reims, the archbishop decided in May 1211 to rebuild the cathedral. Four master builders, the architects of the day, succeeded one another on the site; the sanctuary was completed in 1241, and the main structure only in 1275 (INA).
In Strasbourg, the Œuvre Notre-Dame museum holds some thirty architectural drawings, some of them up to 4 metres tall. They document, the museum writes, the relationship with the “patrons whom these spectacular projects had to convince” (“commanditaires que ces projets spectaculaires devaient convaincre”, in French) (Musées de Strasbourg). The master builder proposed, those who paid decided. Who drew these plans? Tradition attributes one to Erwin von Steinbach, the first known master builder of the Œuvre Notre-Dame; but three plans of the façade have come down to us, and historians do not agree on which would be by his hand (Wikipedia).
The building site. Work most often began with the choir, the part of the church where services are held, and it was used as soon as it was built.
At Notre-Dame de Paris, work began in 1163; the choir altar was consecrated in 1182, and a temporary wall separated it from the building site of the nave (Mullins and Katz).
In Germany, in Cologne, the first stone was laid in 1248; the choir was consecrated in 1322, and a temporary wall closed it off to the west. Work then stopped for more than three hundred years, but sources disagree on the date: after 1520 according to the cathedral’s website (Cologne Cathedral), as early as 1473 for the south tower according to other chronologies (Wikipedia). When it resumed in 1842, builders followed the façade plan drawn around 1280, more than 4 metres tall (Cologne Cathedral workshop). It had been found in two pieces: one in 1814 in the attic of an inn in Darmstadt, the other in Paris in 1815, according to the Freies Deutsches Hochstift (German Romanticism Museum); other sources date the second discovery to 1816. The choir’s temporary wall was only knocked down in 1863, more than five centuries after it was built. An association of donors, the Zentral-Dombau-Verein, provided about 60% of the funding, and the cathedral was completed in 1880.
Back in France, in Beauvais, the choir vaults collapsed in 1284, then the crossing tower in 1573. Work then stopped for good: the nave was never built (Ministry of Culture).
The records. These cathedrals were works of art and of engineering. Built in this way, part by part and at the pace of donations, some nevertheless broke height records. No official register settles the matter; the dates that follow are those of the chronology used by Wikipédia (Wikipédia). Lincoln Cathedral, in England, whose rebuilding had also begun with the choir, between 1192 and 1210 (Wikipédia), is said to have held the height record with its spire, from 1311 until its collapse in 1548, at about 160 metres, a figure some historians question. They would be followed, among others, by Beauvais from 1569 to 1573, Strasbourg and its 142 metres from 1647 to 1874, Rouen from 1876 to 1880, then Cologne and its 157 metres until 1884. For Strasbourg, we have found no official page that confirms these dates.
In Cologne, the cathedral workshop has never closed. Its architect declared the work finished in 1902; the workshop itself considers that this declaration was proved wrong four years later. Around a hundred people work there today (Cologne Cathedral workshop): the cathedral has been in use since 1322, and the care given to the building has never stopped.
The same goes for an application. It is not delivered once and for all, then abandoned: it lives, and has to be adapted for as long as it is in use, just as a building needs upkeep.
On these building sites, the builders did not know when the work would be finished. They began with the essentials, the parts without which the building would have been an empty, unusable shell that even the first generations could not have used. They moved forward at the pace of the money received, and submitted their plans to those who paid.
So what happened? Why, for a work no one has yet designed, do we announce a date and content fixed in advance? Have we lost the know-how of building in parts, each of which is useful? Or a value?
On one side, there is honesty, and sound reasoning that shows how to manage uncertainty and build something of value in spite of it. On the other, there is the wish to hear what reassures: everything, right now, with the feeling that everything is under control. The German sociologist Hartmut Rosa describes a society caught in permanent acceleration (La Vie des idées); Nicole Aubert, in France, speaks of a “cult of urgency” (“culte de l’urgence”, in French) (BnF). One sign of this impatience can even be measured: in 2012, a study of 23 million online video views showed that viewers start abandoning a video if it has not started within two seconds, and that each additional second of waiting increases the abandonment rate by about 5.8% (ScienceDaily).
Are we becoming impatient? Do we want deadlines at any cost, believing that is realistic? And why do we accept it, as customers, as investors, as taxpayers?
There is probably, at present, no definitive answer. Nevertheless, as far as we are concerned, we have taken a stand.
At DEVEDANOS, we develop your custom software, usable within a month, for a fixed monthly budget, and we adjust it continuously as your business evolves. Together, we set the amount and the problem your application has to solve. Our approach predicts what is predictable: the monthly budget and the development days per month. It does not try to predict the unpredictable: what your users will do with a feature before they have it in their hands. Frédéric Leguédois calls this “working without any projection” (“fonctionnement sans aucune projection”, in French) (leguedois.fr).
Your budget buys ongoing work to ease this problem, starting on the first day of development. We aim to solve it completely, but we cannot guarantee that or put a date on it. Your application’s users work with it from the first month of development, and how they use it determines the next feature or features.
There is no longer an estimate to overrun. There is a budget you have chosen, and software your users are already working with.
Our guide covers the questions to ask before signing a quote for developing your custom tool.
Has your project already gone over budget, and does the application need taking over? Our application takeover and redesign page explains how we take over an existing application.
Do you have software to get developed, or a tool that no longer keeps up with your business? Shall we talk?
On 21 October 2026, PHP fixed two critical vulnerabilities, on the same day as GitLab and Node.js. Who is affected, what to do that same day, and how to limit the damage a vulnerability can do.
Continuous Delivery and Continuous Deployment differ by a single step. Why a small, frequent change carries less risk than a big one, with the sources to back it up.
What is a feature flag? Four types of toggles, what to try before adding one, and seven anti-patterns that end up running code nobody has tested.