Development hell: A case study

@xkcd

Shit... I guess this is the first time in the history of this forum when I agree with what you wrote entirely. I am going to open a bottle of wine and celebrate

However... I would like to add something to that. And it is not pleasant for me to write this.
In my opinion, there is a huge problem with culture - inside DCG and community. And this is the most urgent problem to address.

We have created and accustomed to a culture of not delivering and having no consequences.
There is a problem inside DCG of constantly not delivering, breaking promises or having no accountability for promises. And there is a problem within the community of looking for the scapegoats everywhere but not where the problem really exist.
And this is bad. And the problem exists on many levels. I'll just scratch the surface here but I am happy to discuss deeper, if anyone is interested.

In my opinion, currently the biggest problem is with the developers, who are almost worshiped and constatntly shielded by the community, but not held accountable to what they promise and (not)deliver. There was always easier to blame managers, tools, processes or whatever else.

As you have noticed, the managers were changed (multiple CTOs, CEO, board), supporting functions were changed, tools were changed (eg. recently new tool implemented by Patrick), processes were changed. ...And still there is no desired results of delivery on time, as promised and according to expectations. There are excuses and rationalizations instead.
What wasn't changed then? Yeah... the developers. With some minor changes, in the center of the development process these are the same people since years. The same developers, who provide inaccurate estimates to their managers, who promise to finish on time but they never do (or hardly ever), who use new tools and processes. And it looks like they feel pretty comfortable with the situation, because they were made "untouchable".
You can change everything around the developers, but if you don't change them and/or corrupted culture of not delivering on promises (and without consequences) you will ultimately always fail.

Another (big) story is naive claim that developers are always right and they know what they are doing. As a result the project is repeatedly focused on tech, not on customer/user. But in the reality I know, this is the customer (or user) who is ALWAYS right - not developer and not technology.
This is a different story - not necessarily for this topic. Just a food for thoughts.