Tombstones of modern gamedev. The Phenomenon of Self-Inflating Deadlines

The material contains naming and references used in isolation from modern politics, as well as long words that upset Winnie the Pooh.

Cyberpunk 2077. Was postponed by more than half a year.
Atomic Heart. As we waited for the beta version at the end of 2019, we are still waiting.
Escape from Tarkov. Beta testing has been going on for almost five years now.
Vampire: The Masquerade – Bloodlines 2. Postponed for more than two years, much more…
Bayonetta 3. In the time that has passed since the first announcement, it was already possible to release a game, a spin-off, a teaser for a sequel and start filming a series for Netflix – but nooo, we are still waiting …
And others, and others, and others.

Okay, “Escape from Tarkov” and Atomic Heart: ambition, lack of experience, technological fluff. Let’s say.
But the rest of the games – they were at least produced by prominent figures in this field. This is not their first rodeo into the world of AAA projects. Why are they so unlucky?

And what if we shift the focus from gamedev and take a look at IT as a whole?
Everywhere you look – “didn’t hit the deadline”, “crunch”, “better MVP in production than missed deadlines in xxx”, etc, etc…

In addition, two recent publications (on design in IT in general and on YOLO development in game dev) reminded me once again of the potential cause of this phenomenon.
And its name is “the phenomenon of self-inflating deadlines.”

What is the phenomenon?

What in everyday work, what in echoes from more successfully entrenched acquaintances, what in arbitrary sober revelations of unrestrained strangers, I regularly hear very curious theses that guide the development of projects. For example:

We need to occupy a new niche now – we will finalize the product later, if there is demand.
Competitors are too far ahead – we need to catch up with them at any cost, and then we will finalize them on occasion.
Yes, fuck the TK in a quick way, business then, we’ll figure it out along the way, I’ll cover it.
No, we do not have documentation for the work already carried out on the project – you will write it, and then we will plan something on it?
Yes, the chosen solution sucks and will be impossible to maintain. But there is no better, it had to be done quickly.

And so on, and similar arguments on the topic “there is no time to save time.”

Contrary to my custom, I will not vent my indignation (otherwise we will never finish). Just quickly, quickly, I will make some calculations on pure logic and common sense, mixed with experience and observations.

Premise #1: The dictatorship of the proletariat

A long time ago, communism penetrated into the field of calculating real terms for the implementation of projects in IT.
The spirit of the demonic Lenin has risen!
But instead of our women and kulak households, he socialized the right to vote and expert evaluation of terms.
Story Point Poker is it.
“I could do it in X time – but %USERNAME% will probably do it in Y” – this is also his teaching.
It doesn’t matter how long the work will actually take – after all, the estimate of the project’s time consumption is not “from above”, but “from below”!

Only here’s the trouble – the assessment “from below” is needed only in order to proudly declare: “We do not have a waterfall! We definitely plan in sprints according to solid assessment figures!”
But, alas, the transition to post-communism in the assessment of tasks in IT is still impossible because …

Prerequisite #2: TK rare steak

Steaks, which is typical, more than one species.
Perhaps I am a very bad cook and I don’t understand either the recipe or the methodology, but my steaks are of the following types:

too concise – “because you still need to clarify in the process. It’s impossible to foresee everything”
too capacious – “because multi-text is too lazy to read”
too avant-garde – “let’s try this methodology… oops, we all need to learn it!”
too primitive – “uh, where is BPMN?”
julienne. No, this is not a mistake, instead of a steak, they allegedly get julienne from TK because there is a hodgepodge and not enough informational “meat”, waiter, replace the dish …

Which is typical if you rest against the horn and DO NOT make a rare steak (or prepare in advance both a TK-rare steak, and normally ~~fried~~ prepared TK with accompanying ones) – then at the end of stage No. 4 “depression”, the dish made “by the mind” stored up in my stash goes very well … under the friendly whining “well, why so detailed, only ruined time.”

Yes, and the waiter from me, apparently, is also bad.
Although for a situation where the requirements for a dish are obviously impracticable, the result is not bad.
Only by the time when the TK made “by the mind” becomes in demand – all the plans have already been fixed.
(Let’s just write it down: demonic Lenin loves rare steaks from TK)

Premise #3: Madness

There should have been a quote from the famous monologue of Vaas Montenegro. But who is interested – he already knows it. After all, why repeat it over and over again …

Project 1 started, planned, developed, missed the deadline, crunch, saddle cramps and red eyes, passed, phew.
In the mood, they wrote a postmortem in which they swore: nevermore!
Let’s take the next project.

Project 2 started, planned, developed, missed the deadline, crunch, overpowering and carrots in the back, passed, phew.
In the mood, they wrote a post-mortem in which they swore: nevermore x2!
Let’s take the next project.

Project 3 started, planned, developed, missed the deadline, crunch, “work on the weekend – otherwise you’re not a team player!”, passed, phew.
In the mood, they wrote a post-mortem in which they swore: nevermore x3!
And again, and again, and again…

…see the pattern?

Yes, sometimes a small miracle happens and someone initiates a Big Gathering that looks for ways to break this vicious circle.
But the demonic Lenin is not interested in tearing him apart.
Demonic Lenin is interested in a rare TK steak – and something to take. Purely to drink.

And as a result, at the Big Meeting, some set of measures is adopted to study the expansion of the scope of narrowing the time spent in the context of even more advanced project management methodologies yadda-yadda-yadda…

But the real problem is not there.

The only methodology that is more or less stretched over any project fits into three questions:
WHAT do we do?
HOW do we do it?
WHY do we do it?
Moreover, it is necessary to work out these issues in detail already at the stage “but shouldn’t we bang this feature in Q4?”
Because Q4 will come – and we don’t remember what we wanted, we don’t want to remember. It will blow up the timeline.
Because the non-detailed study of the TOR and the unwillingness to devote to reading / discussion also GUARANTEES an increase in terms.

Yes, on the one hand development is a creative work.
On the other hand, there are a finite number of ways to adequately make functional X – and there is a finite amount of time in which it is possible to make functional X in any adequate way.
And for sure, the team has a veteran at its disposal, who can give an adequate estimate of this very time + 30% for a detailed TOR for the functionality.
(and then do not forget to allocate a proportional share for tests-fixes-small-corrections)
It is – YOU CAN standardize and rid yourself of the specter of communism and its howling! And do not continue to spend on endless planning-grooming rallies!

Sounds like heresy… at first. Yes.
Moreover, for such a drunken revelation, I will probably be drained of more than a modest remnant of karma (for some reason, not completely sunk in the article about coincoins).

But think about this.

Prerequisite #4: Mind

“Any rational being strives to work as little as possible.” (c) Jim Statham

Even if the employee is completely loyal, even if his opinion is unbiased and 100% objective, the assessment of time spent by him will be given based on whether the work is piecework or hourly.
And depending on it [выданная сотрудником оценка времязатрат] will be… different! Even with completely identical other things being equal! Even if you manage to get an employee to give an assessment subconsciously, without time for reflection!

British scientists (or Karl Marx, or some other authorities) probably managed to investigate this – but this, in principle, is logically provable without research, it is derived from the very nature of man.

And since we have a common hourly wage, tooooooo? ..

No one is interested in a detailed study of the project for the sake of timely delivery.
(and if I try to give a hint about why EXACTLY, then they will definitely trample me from here … Everyone knows everything – but talking about it is not-acceptable)
Accordingly, the current situation with flights by deadlines (both in game development and in “general” IT), firstly, is absolutely expected (even due to this premise alone, not like all four), and secondly, it is completely inevitable …

No, there are some exceptions, such as significant dates, on which a specific functionality must definitely be delivered, otherwise a carrot on the cheeks.

But more often, either there are no such dates, or they managed to do it by the date, but instead of the release, they threw out the MVP, who is suddenly forced to fight with long-developed competitors, as happened, for example, in the case of Hood: Outlaws & Legends … again…

What to do with it…

Having soberly judged that I still have time to learn bad things, I preferred to blow the dust off my completely non-IT diploma. I am not ready to continue strangling my own conscience, even if only for the sake of the remaining “innumerable treasures” of modern IT. And there are no other options.

And you?